A small excerpt from the IoC Container doc

January 7th, 2009

Twitter followers probably know that I’ve been working on an IoC Container document for my team. It goes over several aspects – including why in my view “DI” is a wrong term and should be banished – from history to features and scenarios. I got permission to release some bits of it in the future. The following however is an excerpt I thought I should share.

Another important aspect of common use of IoC Containers lies on the fact that the components that make up an application play no role in defining or constraining the implementation that can satisfy a dependency. The minimal safety is provided by strongly typed contracts, but it ends there. All binding is left for an external entity – the application host.

Given that the ultimate goal is to reduce coupling and promote reuse, this approach makes a lot of sense as it allows components to be used anywhere, with or without a container.

The component can express what is required or optional using natural OOP idioms. For example, multiple constructors will allow the IoC Container to call the one it can satisfy the most arguments. Also public writable properties are considered optional dependencies for most containers. Note that the container is just playing the role of a user of the class, checking constructor overloads and properties that they can provide values for, absolutely no different from a human interacting with the same class.

By sticking with these natural idioms a class will be naturally decoupled, easy to be reused and easy to be tested. The fact that it also plays well with IoC Containers is a consequence of the decoupling exercise, and should not be misunderstood as the main driver.

Categories: IoC, MS | Top Of Page | 7 Comments » |

7 Responses to “A small excerpt from the IoC Container doc”

Heinrich Breedt Says:


Could you expand a bit on why you dont like the term DI ?

hammett Says:

I’ve done that several times, and this little excerpt also reveals a bit of the why. Anyhow, wait for the full article.

Mike Hadlow Says:

Very nicely put.

I really like the way you’ve emphasised the core OOP principles, and the fact that decoupling components is good regardless of whether one is using an IoC container.

There seems to be a common naive use of IoC containers that involves having ‘resolve’ calls peppered throughout an application. I’ve seen plenty of blog posts that show this. A core message of IoC container use should be: having a reference to the IoC container anywhere in your application other than the initial setup is an anti-pattern.

I’m looking forward to the full article. Is this part of your ‘IoC container cookbook’?

hammett Says:

Mike, I’ve also touched this topic on my doc. I guess it’s easier to write a container than to think about what you’re doing/encouraging…

It’s not a cookbook, but history and somewhat formal analyze. I’m not sure whether I’ll publish here or in a magazine. All I can say is that a substantial part will be available publicly at some point.

Glad you like it, btw

Dependency Injection Inversion | YOOT Says:

[...] A small excerpt from the IoC Container doc [...]

Matt Hinze Says:

Just a nudge – did you ever release this document?

hammett Says:

Thanks for the nudge. It completely slipped my task list. I’ll see what I can do, but I’m fairly busy these days with other stuff, so bear with me.

Leave a Reply