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:
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".
This blog contains the thoughts and discoveries of Tim Barcz, a technologist with a interests in computer programming technologies.