IoC containers finally make sense

I think I've just had a small epiphany. I've never really grokked the need for Inversion of Control containers, like Castle Windsor, StructureMap or Unity. They've always seemed like overkill. And of course, the reason I've felt like this is that they have been overkill - for the projects where I would have used them.

It's just another case of the right tool for the right job.

Most of the projects I've used have been loosely coupled by default, and while I've used dependency injection, it's never been too many layers deep, so setting up the dependencies has never crossed boundaries they shouldn't have crossed. Sometimes I've put them in config, and a container would definitely have saved me some work here, but not too much. I've always made do with a poor man's solution.

This snippet of code (from an msdn article) showed me how, working on different code, dependency injection would have led me too far down the plug hole:

// Somewhere in UI Layer 
InvoiceSubmissionPresenter presenter = new InvoiceSubmissionPresenter( 
  new InvoiceService( 
    new AuthorizationService(), 
    new InvoiceValidator(), 
    new InvoiceRepository())); 

It was always this wiring up of the dependencies that bothered me, but I was never far enough aware from the deepest layer for it to be properly wrong. Fixing this is exactly what the IoC abstraction is good at. That you get goodies such as lifetime management (per thread, singletons, etc), auto-wiring of dependencies and dynamically generated decorators is just icing on the cake.

Now it's just a case of figuring out which one to use.