Join GitHub today
Refactoring of the Dependency Injection component (v3) #6
ZF3 Refactoring Proposal
With the version switch to 3 it's a good time to refactor
TODO's (Requested Changes)
Make this component more leightweight by removing too complex scenarios like getter or property injections. Constructor-Injection is much easier to implement and debug and lowers the risk potential issues like cyclic dependencies.
Fore more complex scenarios there is always zend-servicemanager which should be used.
Add support for generating an optimized di container
This should generate a container and injectors by utilizing the
Refactor ServiceLocator and ServiceLocatorInterface
The current ones are most likely never used in the real world or by Di.
Make it a ZF3 Component
This component should easily integrate by using the zend-component-installer or by adding it as a zend-mvc module to the application config. This approach
So people can decide whether they stay with ServiceManager only or combine it with Zend\Di.
Better integration with ServiceManager
The ZF2 integration of Di into the ServiceManager/Mvc is using an odd factory
Assuming the service manager has configured the Zend classes as services:
While the DB Adapter for Foo is taken from the ServiceManager, the auth service
Since the ServiceManager in ZF3 now uses Interop\ContainerInterface, we can pass the ServiceManager
When Using the Module approach above, Di can register an abstract service factory to handle class instanciation.
Change the parameters array role
While the concept of providing complex parameters to a service locator (or its factories) is
Mapping a parameter hash is not only a pain to resolve (especially for nested dependencies),
To remove this complexity and allow faster instanciation the provided parameters array will only be used for
changed the title from
[WIP] Refactoring of the Dependency Injection component
Refactoring of the Dependency Injection component
Nov 4, 2017
Awesome pull request - I love the fact that you also included documentation!
I'll try and review this week so we can get a release out. When we do, we'll likely need a new version of zend-servicemanager-di as well, which I'll need your help with to ensure correctness.
Once those are in place, would you be open to maintaining these two components?
Thank you. I created it with PSR-11 and full zend-servicemanager compatibility in mind, so zend-servicemanager-di would not be a requirement anymore. But the service factory and module/config provider could be moved to zend-servicemanager-di if it fits better there, of course.
I'd love to take the opportunity to maintain these components.
Here's my initial feedback:
- Since this will be a new major version, bump the minimum supported PHP version to 7.1. (This is something we decided earlier this year.) That means you can also bump the PHPUnit version to the v6 series.
- Typehint against psr-container instead of container-interop. This will still work with zend-servicemanager; it should use versions of container-interop that extend the psr-container interfaces, which would allow using the two together.
- Use zendframework/zend-coding-standard for checking/fixing coding standards, instead of php-cs-fixer.
- Remove HHVM support.
- Write up some migration documentation: how would a consumer of the v2 series migrate to v3? What are potential pitfalls?
- Keep the v2 documentation, but potentially move it to a "legacy documentation" section, so folks still on v2 can find information.
I think with these latter two items in place, in particular, I can better review the impact, and users will have a better experience in evaluating upgrades to the new version.
Thanks a ton for all the work you've done so far! A net loss of lines of code is ALWAYS welcome!
Thanks for your feedback, I will change it accordingly.
About the PSR container hints, do you want me to replace them with Interop\Container or leave it as is?