Everything begins with the call-up of the http://localhost/sayhello URL. The HTTP request reaches the web server, which after consulting .htaccess decides that the index.php has to be processed by the PHP interpreter. In the scope of the index.php, the autoloading is initially configured and subsequently the application’s init() method is called up.

<?php
    Zend\Mvc\Application::init(include 'config/application.config.php')
        ->run();



ServiceManage

The ServiceManager instantiated there:

<?php
    // [..]
    $serviceManager = new ServiceManager(
        new ServiceManagerConfig($configuration['service_manager'])
    );


As a result of the transfer of ServiceManagerConfig, the ServiceManager is equipped with

several standard services which Zend\Mvc requires for smooth functioning. In addition the

corresponding configuration is transferred tothe ServiceManagerConfig from the previously loaded

application.config.php.


The ServiceManager is a sort of Zend_Registry with extended functions. Whereas the Zend_Registry of Version 1 could merely file existing objects under a certain key and subsequently load them again (key value storage), the ServiceManager goes several steps further.



Services and service generation

In addition to the administration of services in the form of objects, a “generator” can also be registered for a key, which generates the respective service initially when needed. To achieve this,

either classes (fully qualified, i.e., if necessary, with declaration of the namespace, which are then

on request instantiated, for example in the form

<?php
    $serviceManager->setInvokableClass(
        'MyService',
        'Helloworld\Service\MyService'
    );

or factories can be deposited.

<?php
    $serviceManager->setFactory(
        'MyServiceFactory',
        'Helloworld\Service\MyServiceFactory'
    );


In order for the ServiceManager to be able to manage the MyServiceFactory, the latter has to

implement the FactoryInterface, which requires a createService method. This method is then

called up by the ServiceManager. As light-weight implementation of a factor, a Callback function

can be directly transferred.

<?php
    $serviceManager->setFactory(
        'MyServiceFactory',
        function($serviceManager) {
            // [..]
        }
    );


Alternatively, can an abstract Factory also be analogously filed, where by this is added without

Identifier; this is shown here exemplarily in a Callback variant.

<?php
$serviceManager->addAbstractFactory(
    function($serviceManager) {
        // [..]
    }
);


In addition, so-called “Initializers” can be filed; they ensure that a service is equipped with values

or references to other objects when it is called up. “Initializers” can be so conceived that the inject

objects into a service when the respective service implements a defined interface. We will see this

in action again later. At the moment, we should only remember that they exist. All services made

available by the ServiceManager are so-called “shared services”, this means that the instance of a

service—generated when needed or already present— can also be returned at a second request of just this service instance. The instance of the service is thus reused. This is valid for all standard services defined by Framework; the only exception in this context is the EventManager. If a new service is registered, one can also prevent the reuse of instances.

<?php
$serviceManager->setInvokableClass(
    'myService',
    'Helloworld\Service\MyService',
    false
);



Standard services, Part 1

At the very beginning of request processing, the ServiceManagerConfig ensures that a number

of standard services are made available. It is important to realize that there are services in the

ServiceManager, which can in part only be used by Framework (or more exactly by its MVC

implementation), whereas some other services are also useful for the application developer, for

example in the context of a Controller. This will become clearer somewhat further along.



Invocables

The following service is made available as an “invocable”, i.e. by specifying a class, which is then

instantiated when necessary. SharedEventManager (Zend\EventManager\SharedEventManager): Allows the registration of listeners for certain events, also when the event manager required for this is not yet available. The SharedEventManager is automatically made available by a new EventManager when this is generated by the ServiceManager. Further explanations of the SharedEventManager will be found later in the book.



Factories

In the context of the ServiceManager, Factories are there to make services available, which do not

exist until the real request occurs, but rather are built by a Factory “on demand”. The following

services are made available indirectly by a factory as standard. SharedEventManager (Zend\EventManager\SharedEventManager): The EventManager can generate events and inform registered listeners about them. It can also be requested via the Zend\EventManager\EventManagerInterfacealias.

ModuleManager (Zend\Mvc\Service\ModuleManagerFactory): Administers the modules of a

ZF2 application.



Configuration

The ServiceManager is thus decisively controlled for use in the scope of request processing by

two configurations: The ServiceManagerConfig, which defines a number of standard services for

request processing, and also by the application.config.php or module-specific configurations,

respectively. In each case, the service_manager key is essential for this:

<?php
return array(
    // [..]
    'service_manager' => array(
        // [..]
    )，
)；


Below the service_manager'keys, the following keys are then possible:

services: Definition of Services with the aid of already instantiated objects.

invocables: Definition of services by declaration of a class, which is instantiated when

needed.

factories: Definition of factories, which instantiate serves.

abstract_factories: Definition of abstract factories.

aliases: Definition of aliases.

shared: Allows the explicit declaration of whether a certain service can be used a number of

times or should be re-instantiated if again required.


As soon as the ServiceManager is available, the application.config.php is, then as a whole, i.e.

also with the other non-ServiceManagerrelevant sections, itself made available as service.

<?php
// [..]
$serviceManager->setService('ApplicationConfig', $configuration);


This is important because other components, such as the ModuleManager or ViewManager, also access these services.


At the present time, the ServiceManager (equipped with diverse standard services) is thus in

readiness and, in a manner of speaking, is only waiting for the show to begin. For, up to now

not much has happened except for a few basic preparations. In fact, at this point nearly all of the

above-mentioned services do not yet exist because they have not yet been requested and are only

generated when necessary.