I\'m going trough ZfcUser to learn more about modules in Zend Framework 2. In the Module.php you can see
\'invokables\' => array(
\'ZfcUser\\Authentication\
There is no convention but I do think you should consider how the invokables will be used.
For example the first three rely on an interface called ServiceManagerAwareInterface
therefore these instances need to come out of the ServiceLocator
to function as intended. Given that they are fully qualified class names, I would assume that the ZfcUser developers do not envisage people overriding these.
And the latter two are aliased, so if a developer wanted to override these invokables it would be a straightforward task. An example of this is the developer chooses to extend ZfcUser\Service\User
to add/modify functionality, then creates line in his module's invokables:
'invokables' => array(
'zfcuser_user_service' => 'MyModule\Service\ZfcUser',
),
Then any code using zfcuser_user_service
would receive an instance of MyModule\Service\ZfcUser
rather than ZfcUser\Service\User
.
In contrary of the other answers, I can state that there IS a convention, which is to use fully qualified class names for service names wherever possible (and fake class names where the service is virtual and instance of another class).
If the problem is just about how ZfcUser does it, I can tell you that ZfcUser
is not state of the art (currently 0.1.*
) and needs a rewrite. You could look at BjyAuthorize for a better example.
I use either the FQCN (Fully Qualified Class Name) of the class that is defined as a service, or the FQCN of the interface it implements, which helps avoiding that the user consuming the service uses API not specified in the interface, and just in the implementing class.
Also, consider that it makes no real difference if you use \
or _
or lowercase or uppercase service names, since everything is normalized in the service manager.
That basically means that zfcuser_service_user
or ZfcUser\Service\User
are the same.
To recap, here's a good practice you could follow:
'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',
),
This is both easy to remember and allows end-users of your service to look for Namespace\MyInterface
and find what they were looking for.
Use it also for factories and for services spawned from abstract classes if possible, since it makes things easier to remember for everyone.
There is no convention about how aliases are named. You should only give your aliases a unique name so you don't get naming conflicts with other modules providing the same service. I use the FQCN in my project as well, because it avoids any conflicts 100% and it is very clear which class you are requesting from the service manager.
In the end it all comes down to personal taste, but I'd try to confirm yourself mostly to a single naming strategy and not mix up several tastes.