Your IoC Container Choice is Not a Feature of Your Application

Tim Barcz — Mon, 30 Mar 2009 02:51:00 GMT

I don't want to be a wet blanket, but someone's got to put a stop to the IoC love fest going on out there. An Inversion of Control (IoC) container , for those of you were aren't yet familiar, allows you to retrieve instances of objects at runtime. A relatively common solution to a common problem. In the .NET world there is no lack of choices of IoC containers:

(I won't go fully into IoC, but If you'd like more resource you can read Martin Fowler's article on the subject or post specific questions in the comments or contact me through. Read on, there is value here in this post for you.)

Let me state clearly now, IoC containers are a means to an end and NOT a feature of your application. The goal is to have loosely coupled applications, IoC containers help get you there, but you can absolutely have a loosely coupled application without an IoC container (see the Gang of Four creational patterns).

Occasionally I'll hear some comment about IoC and how great a certain container is or how an application would be so much better if another, sexier, container was used. Here are some recent tweets that illustrate:

Man i love #StructureMap, always finding new things i can do, and have fun doing them
really need to look at structuremap, but we''ve invested a lot into castle with our own facilities/resolvers/etc
Ninject is da bomb!
Switched from Windsor MicroKernel to Ninject in 10KLOC project in < 1 hour by creating a little proxy. Now to complete the conversion.
It is a talk on Castle Windsor so i guess Ninject will not do.
Can't imagine why somebody would use Ninject beside the fact that it's PURE AND UTTER AWESOME. Yeah! Ninject FTW.

Some of the statements above are probably innocuous, but some rub me slightly the wrong way. Specifically the two comments above about switching from one container to another. There are probably times when the choice of one container over another makes sense, but I would bet that these scenarios are the exception and not the rule.

Choosing one container over another won't make your application a success, the architecture, or lack there of, will have far more of a say on your application than will your container choice. As yoda might say, "The container you choose does not a good app make".

Tim Barcz : Rant, Windsor

Your IoC Container Choice is Not a Feature of Your Application