inversion of control - Abstract factory pattern on top of IoC?

Question

I have decided to use IoC principles on a bigger project. However, i would like to get something straight that's been bothering me for a long time. The conclusion that i have come up with is that an IoC container is an architectural pattern, not a design pattern. In other words, no class should be aware of its presence and the container itself should be used at the application layer to stitch up all components. Essentially, it becomes an option, on top of a well designed object-oriented model. Having said that, how is it possible to access resolved types without sprinkling IoC containers all over the place (regardless of whether they are abstracted or not)? The only option i see here is to utilize abstract factories which use an IoC container to resolve concrete types. This should be easy enough to swap out for a set of standard factories. Is this a good approach? Has anyone on here used it and how well did it work for you? Is there anything else available?

Thanks!

Answer 1

As you have already figured out, Dependency Injection (DI) itself is only a collection of patterns and techniques.

At the root of the application we wire up all necessary object graphs. This place is called the Composition Root, and we can use a DI Container to do this wiring for us, or we can do it manually (Pure DI).

The point is that there's only one place in your application where there's a strong reference to a particular piece of technology (your DI Container). The rest of the app is blissfully unaware of how the object graph was wired up - all that matters is that all required dependencies were correctly injected (and you can use Constructor Injection with Null Guards to guarantee that this is so).

The Abstract Factory pattern is a very useful pattern when it comes to DI. In essence, use Abstract Factory when:

• You need to supply one or more parameters only known at run-time before you can resolve a dependency.
• The lifetime of the dependency is conceptually shorter than the lifetime of the consumer.

Examples and more information is available here:

• Is there a pattern for initializing objects created via a DI container
• Can't combine Factory / DI
• Which DI container will satisfy this
• Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?)
• Design - Where should objects be registered when using Windsor