Zend Di vs ServiceManager dependency injection containers

Question

What is DI for and what is its use case, when we have ServiceManager?

They appear to be similar since in configuration files for both zend-di and zend-servicemanager we can set up some options such as aliases and invokables.

I am trying to get a better understanding of what is happening behind the scenes with these components, and documentation did not give me enough info.

Could you please tell me what the difference is and when I should use Di instead of ServiceManager?

Fillian

There is a good discussion about containers in general on php-fig.org/psr/psr-11/meta – Sim

modern advice seems to be "do not use DI or SM" yourself, unless they are already part of your framework. Zend uses Factory-based Service Manager (which is essentially a restricted DI Container), where you must take care to not inject any container into any of your own classes, but you can use the container as part of the set up of your application. i.e. in Zend you can use facilities of the framework itself to customize how your dependencies are wired up. Some recent examples are here: docs.zendframework.com/tutorials/getting-started/… – Sim

Answer 1

Zend\DI relies on magic, like reflections, to detect and inject dependencies while service manager uses user provided factories. That is main difference.

Di sort of deprecated in community in favor of SM due to complexity, debugging and performance issues. It supposed to be good for RAD, but you need above average knowledge to use it properly.

On the other hand SM have pretty verbose and explicit wiring, you can open your code year later and easily figure out what is going on.

Shay

That is a good answer, I remember using DI early on and I would not go back to using it. – Dominick

does it mean that i may refuse to use di and sm will do the work aswell? – Fillian

Exactly as Xerkus pointed out. Di-Stuff is pretty much considered depricated, DI-Containers simply have been overly complex. The ServiceManager resolves the same core-problem in a so much more user-friendly way. – Enjoyment

@Fillian generally service manager is recommended. Zend\Di is good but I have no tasks where i can benefit from it, may be if i will need to do prototyping of something complex. – Shay

Xerkus, I would slightly update your answer for future reads. Di is not magic and pure reflection. Zend\Di is a powerful component but quite complex as well. You can tune Di to make it as fast as the service manager, but you need to compile your definitions into something that looks like service manager factories. Di is pluggable where at this moment reflection is the only "reader" of the definitions. There were other "readers" planned, but due to the complexity, a service manager component was written along. This was so much more in favour that the complete code base switched to the SM. – Therapeutics

Answer 2

Zend\Di takes care of wiring your classes together, whereas with Zend\ServiceManager you have to wire things manually and write a factory closure for every class you want to instantiate.

Zend\ServiceManager is much faster since it does not rely on the slow Reflection API. On the other hand, writing closures for large applications with hundreds of classes becomes very tedious. Keeping your closures up-to-date will get trickier as your application grows.

To address this problem, I have written a Zend Framework 2 module called ZendDiCompiler. It relies on Zend\Di to scan your code and auto-generates factory code to instantiate your classes. You get the best of both components: the power of Zend\Di and the performance of Zend\ServiceManager.

I have put quite a bit of work into the documentation of ZendDiCompiler and some easy and more advanced usage examples are provided, too.

Hydrofoil

Answer 3

Basically the difference is as follows:

• Zend\ZerviceManager = Factory driven IoC Container
• Zend\Di = Autowiring IoC implementation

Zend\Di was Refactored for Version 3. Its behaviour now more solid and predictable than v2 and it is designed to integrate seamlessly into zend-servicemanager to provide auto-wiring capabilities (no more odd magic). Since it uses PHP's reflection api to resolve dependencies it is slower than a factory driven approach. Therefore version 3 comes with an AoT compiler to create a pre-resolved Injector that omits the use of Reflection. An additional benefit: The generated factories can also be used with Zend\ServiceManager directly.

There is a guide for using AoT with both components: https://zendframework.github.io/zend-di/cookbook/aot-guide/

Moyer