DI container versus factories
I know there are many aricles and threads on Dependency Injection, but not many on Depenedency-Injection-Containers. I found this Fabien Potencier quite useful, although it targets PHP. However, the more I read about these containers, I come to the conclusion that this is not a simpler set of factory methods, is it true?
A deeper and more specific view: When introducing an object dependency
foo.Bar = new Dependency();
I could write
foo.Bar = new myFactory.CreateDependency();
or with container
foo.Bar = myContainer.CreateDependency();
Here, the container in the last approach lacks just one but many other methods for creating other types, so it's just a container for factory methods, right?
source to share
The whole point of DI containers is that you never need / should write code like
foo.Bar = myContainer.CreateDependency();
Considered anti-pattern. The DI container should only be used once at the root of the composition (this is the main pattern for using a DI container).
The DI container automatically creates objects and injects dependencies through constructors or properties based on configuration. In the case of Factory, you have to do everything yourself. Besides creating DI containers, you provide:
LifeTime Management. So every time a dependency is needed, the container can inject the same object (single point lifetime) or return every time every time.
Limited AOP features such as intercepting method calls and executing custom logic before and after methods.
You can have a look at this book Dependency Injection in .NET . It helped me understand DI containers, use cases, and dependency injection in general.
source to share
DI-Container can be thought of as a large set of smart factory methods that are customizable in several ways (code, xml, auto-mapping). I called these factory methods smart because the container keeps track of registered types and uses them to create more complex objects. When using factories, you need to install these dependencies yourself, otherwise you are already using the container dependency.
source to share
You can see the DI container / library as a factory structure with many high level object construction methods (via reflection). This is useful because you usually don't need to write any high-level method, for example, to load plugin bundles and get plugin data types. But the disadvantage is that reflection is slow and it is wise to use it during the initialization phase of the application. But if you want to create many small objects with it at runtime, it will slow you down.
On the other hand, your own factories are custom made and usually contain a list of specific implementations and a large switch case, card, or something like that. They are faster, but you need to write all the object construction logic yourself.
You don't have to choose between these two options, which you can combine. For example, you can build complex factories via DI
source to share