Dependency Injection Container vs Registry pattern

Question

I understand that the Dependency Injection principle is all about decoupling code. Instead of making new instances in the classes, instead you inject them, which make them loosely coupled.

Now if I have to pass on a set of objects that will be used through several classes throughout my application, I can make a container (commonly called dependency injection container).

That is exactly what i am doing because I have to pass a config object, a logger object, a translator object, etc. which will be used through several classes instances of my application. I am passing the whole container through several classes, even if not all of the classes need access to all the objects within the container. This led me to the following question: what is the difference if I create a global Registry and put the objects in there, then retrieve them like Registry::getInstance()->get('logger'); ? Wether I use a global registry or a dependency container, class isntances will have access to all the objects within the container or registry, even if they don't need to see/access all of them.

Conclusion: What is the difference if I pass a dependency injection container along my classes or a global Registry ?

Answer 1

_{Note: sometimes people use Registries by different names. The common ones that i have seen as: Locator, Context and System.}

Use of global Registry causes your code to be tied to the class name of said Registry. It means that you cannot test your code independently. And the way, how registry is set up, lies to you: you can never know which instance will be required.

It is quite common for people to confuse DI Containers with Registries.

DI Container is not something that you inject into a class. Instead it is an enhancement for factories: it determines that class Foo requires instance of Bar to be injected in the constructor. Then, depending on setup, it either acquires new instance of Bar or uses the existing one, to provide said dependency.

• In a simple factory you usually have to hard-code the dependencies, that will be injected. In this situation, what factory can build, is limited by "footprint" of class's constructor.

• When factory uses as DI container, it can produce instances with various dependencies. In this setup, your factories focus on constructing instances that are tied to some specific namespaces (or other high-level) logical groups of classes.

Answer 2

I think the point missing here is CompositionRoot .As per DI Principle once you define your bindings in the Composition Root , then you can use the reference throughout the application. That is the value DI Container brings.

As per definition "A Composition Root is a (preferably) unique location in an application where modules are composed together."

I will add that a Composition Root also a unique location where all important decisions about your applications behavior takes place. That is what object to use in what situation.This is the heart of a OO system where interaction between the objects deliver the behavior of the system.

Answer 3

I agree with most of what teresko has said and i would like to add some points:

• If you feel that your services are shared among many different instances then you can register them as Singeltons with the container but then you will have to think about multi-threading if it is an issue for your.
• Whenever you feel that your back is against the wall in a dependency injection scenario then remember that factories (Abstract Factory Pattern) are almost always the solution.
• The services you mentioned seem like a cross-cutting concern so i would use AOP techniques to avoid bloating my codebase with those concerns, this will make the code much more cleaner.