Archive for the ‘IoC’ Category

Workshop on Inversion of Control Containers

February 18th, 2009

Next Friday (Feb-27) I’ll be in Seattle doing a workshop on one of my favorite topics: Inversion of Control Containers. Expect some digressions on the story of ioc containers, how they evolved, what problems they solve and what problems they introduce. Also why I think the DI term should be banished – call me a purist. Windsor, MEF and maybe others will be on my radar.

If you want to attend, keep an eye on this page. Currently registrations are closed, but should open in a few days.

I truly hope I dont have a cold next week :-)

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 » |