What is the point of calling invokables as classes?

Question

I go through ZfcUser to learn more about modules in Zend Framework 2. In Module.php you can see

'invokables' => array( 'ZfcUser\Authentication\Adapter\Db' => 'ZfcUser\Authentication\Adapter\Db', 'ZfcUser\Authentication\Storage\Db' => 'ZfcUser\Authentication\Storage\Db', 'ZfcUser\Form\Login' => 'ZfcUser\Form\Login', 'zfcuser_user_service' => 'ZfcUser\Service\User', 'zfcuser_register_form_hydrator' => 'Zend\Stdlib\Hydrator\ClassMethods', ), 

Now, what is the difference between giving classes a real abbr similar to "zfcuser_user_service" compared to their fully qualified name? I suppose there are no technical differences, but maybe there is an agreement on how to name invokables, how ZF relies on them, how to name them?

Answer 1

Unlike other answers, I can say that there is an agreement that should fully use the names of qualified classes for service names everywhere is possible (and fake class names where the service is virtual and an instance of another class).

If the problem is how ZfcUser , I can tell you that ZfcUser not up-to-date (currently 0.1.* ) And needs to be rewritten. You can look at BjyAuthorize for a better example.

I use either the FQCN (Fully Qualified Class Name) of the class that is defined as the service, or the FQCN of the interface that it implements, which helps to avoid the fact that the user using the service uses an API not specified in the interface, and only in the implementation class.

Also note that it does not matter if you use the names \ or _ or lowercase or uppercase names, since everything is normalized to the service manager . This means that zfcuser_service_user or ZfcUser\Service\User match.

To repeat, here's a good practice:

 'invokables' => array( // interface FQCN 'Namespace\MyInterface' => 'Namespace\MyImplementation', // no interface available 'Namespace\ClassName' => 'Namespace\ClassName', // no interface nor own implementation available (similar to an alias) 'Namespace\MyStuff' => 'OtherNamespace\Stuff', ), 

It is easy to remember and allows end users of your service to search for Namespace\MyInterface and find what they were looking for.

Use it also for factories and services derived from abstract classes, if possible, as this makes it easier for everyone to remember.

Answer 2

There is no agreement on what aliases are called. You should specify only your nicknames unique name so that there are no name conflicts with other modules that provide the same service. I also use FQCN in my project because it avoids 100% conflicts, and it is very clear which class you are requesting from the service manager.

In the end, it all comes down to personal tastes, but I would mostly try to confirm one naming strategy, and not mix several tastes.

Answer 3

There is no agreement, but I think you should consider how invokables will be used.

For example, the first three rely on an interface called ServiceManagerAwareInterface , so these instances must exit the ServiceLocator function as intended. Given that they are fully qualified class names, I would suggest that ZfcUser developers do not assume that people override them.

And the last two are aliases, so if the developer wanted to override these invokables, that would be a simple task. An example of this is a developer who wants to extend ZfcUser\Service\User to add / change functionality, then creates a line in his invokables module:

 'invokables' => array( 'zfcuser_user_service' => 'MyModule\Service\ZfcUser', ), 

Then any code using zfcuser_user_service will get an instance of MyModule\Service\ZfcUser , not ZfcUser\Service\User .