What is the sense of naming invokables like classe

2019-03-14 04:30发布

问题:

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\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 like "zfcuser_user_service" vs their fully qualified name? I assume, there is no technical difference, but maybe there is a convention how to name invokables, as ZF relies on them, how to name them?

回答1:

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.



回答2:

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.



回答3:

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.