4

I know there are many articles and threads on Dependency Injection, but not as much on Dependency Injection Containers. I found this one by Fabien Potencier quite helpful, although it targets PHP. However the more I read about those containers I come to the conclusion that such is none more then a simple collection of factory-methods, is this true?

A deeper and more concrete view:
When injecting a dependency to an object

foo.Bar = new Dependency();

I could also write

foo.Bar = new myFactory.CreateDependency();

or with a container

foo.Bar = myContainer.CreateDependency();

Here the container within the last approach does not have only one but many other methods to create other types also, so it is just a container for factory-methods, right?

Improve this question

4 Answers 4

Reset to default
3

The whole point of DI containers is that you never need/should write code like 

foo.Bar = myContainer.CreateDependency();

It is considered an antipattern. DI container should be used only once in Composition Root(it is a main DI container usage pattern).

DI container automatically construct objects and inject dependencies via constructors or properties based on configuration. In case of Factory you have to do everything yourself. Beside creation DI containers provide you with:

LifeTime management. So every time dependency is needed container might inject the same object(singleton lifetime), or return new everytime.

Limited AOP capabilities such as method call interception and executing custom logic before and after methods.

You might take a look into this book Dependency Injection in .NET. It helped me a lot to understand DI containers, patterns of usage and Dependency injection in general.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

But how does contaienr know WHEN to construct a new instance of any class?
Of course, there should be explicit call to DI container and this should be done at some "entry point". For example in web app this point is creating of controller where resolve is called: container.Resolve<ISomeController>. But SomeController itself is ignorant that DI container is used. That is the essence of Composition Root pattern.
2

You can see DI-container/library as a factory framework with lots of high-level object construction methods (via reflection). It is useful because usually you don't have to write any high-level method, for example, for loading plugin assemblies and getting plugin data types. But the downside is that reflection is slow and it is reasonable to use it during your application init phase. But, if you want to create lots of small objects with it during runtime, it will slow you down.

On the other hand your own factories are custom made and usually contain list of concrete implementations and big switch-case, or map or something like that. They work faster but you have to write all object construction logic yourself.

You don't have to choose between these two options you can combine them. For example, you can construct complex factories via DI

Improve this answer

Comments

1

The DI-Container can be seen as a big set of intelligent factory-methods, which is being configured using several ways (code,xml,auto-mapping). I called these factory-methods intelligent, because the container keeps track of its registered types and uses them for the creation of more complex objects. When using factories, you'll need to set these dependencies yourself, otherwise you're already using a dependency-container.

Improve this answer

Comments

0

Ideally the code should be unaware it's running with DI. It just externalizes its dependencies and assumes they're provided.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.