Dependency Injection (DI)

I was late to the part on Dependency Injection, or so I thought. I'd been reading and trying to get my head around IoC (Inversion of Control) for some time when I decided to delve deeper and started reading the book Dependency Injection in .Net. After reading about 50 pages it dawned on me, I'd been designing my software with DI in mind for years.


My background in strongly typed modern (at the time) C++ had always enforced reference (pointers) access via an interface (or pure virtual class) in conjunction with the pattern identified by Kevlin Henney called PFA (Parameterize From Above), complemented by my own personal hatred of the global singleton "don't know how to solve a problem so I'll just cheat" anti-pattern had made me subconsciously an advocate of DI. Like many of the GoF (Gang of Four) patterns named in the book Design Patterns : Elements of Reusable Object-Orientated Software I'd been using them for years, I just didn't know they had a name (remember all this book really did/does is allow us to talk about a pattern using the same language, the patterns are just a result of good design and are pretty obvious). Now I understood, now I could talk to my other developers using the same language.


Fast forward and now my main development language of choice is C# and safe in the knowledge that DI is nothing new, I continue reading to find out what specifically I didn't know. The gap in my own implementations can be termed the IoC Container, the mechanism for resolving the dependencies. Now strictly speaking you don't need to use a 3rd party IoC Container as you can do what I had been doing for years and just create your own for what you need and wire it all together yourself. Its not that difficult and sometimes that's all you need.

Note: Do not confuse the IoC Container with a service locator, the IoC Container is much better and the service locator goes against my opinions on a global top level singleton - The service locator is that singleton to bridge all singletons.

IoC Containers as supported by numerous frameworks provide at least 2 or 3 of the following features:

1. Automatic Dependency resolution
2. Lifetime management
3. (optionally) File based configuration.

In reviewing which IoC/DI Containers I should be using I was edging toward Unity (being a MS Stack kind of guy) when I stumbled across this comparison on the performance of the respective IOC Containers. This then led me to my current choice of preferred IoC Container, namely Autofac, its light weight, and is so simple to use that even doing you own DI wiring is not really worth it. Keep in mind though that using an IoC Container is a high-level choice for your application, web service or whatever (i.e. at the start of your app loading or registering). The key is that by using DI in your design and implementation you open up the opportunity to use any IoC container and MUCH more importantly it also means that you can isolate and unit test properly (you are unit testing?). I see the choice of which IoC container to use to be a decision that does not have to be made today and even if you had decided which one to use, you can always change your mind tomorrow.