At the weekend I gave the a presentation “Inversion of control containers Vs HandRolled” showing the difference between using an Inversion of Control (IoC) container versus doing the dependency injection yourself.
I was asked a question on twitter Tuesday
“@philpursglove: @nathangloyn meant to chat with you at #ddd10 about why DI != IoC. Have you got a blog on this?”
There was a brief exchange on twitter about this but I wanted to just put my thoughts down around this.
For me Dependency Injection is a pattern, it is where a class that uses other classes i.e. is dependent on the classes, has these dependencies injected into it, whether this injection is via the constructor, property or methods.
When people talk about IoC they most commonly think of a container such as Ninject/StructureMap/Autofac, they think about it as a mechanism to handle the injection of the dependencies so they don’t have to worry about writing all the code to do this.
I believe IoC isn’t just the mechanism to implement DI but its exact definition is a little more difficult to pin down, if you read this wiki on the Castle project documentation then IoC is all about frameworks if you read Martin Fowlers article then its a principle to bear in mind when building your application. One thing that Martin Fowler does say in his 2005 article:
“There is some confusion these days over the meaning of inversion of control due to the rise of IoC containers; some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use.”
He is describing DI as a specific style of IoC but I believe it simpler to think of DI as a separate pattern that can stand by itself but could easily fall under the general principle of IoC, hence DI != IoC.
Interestingly the closer you look at IoC to me it seems very similar to the Dependency Inversion Principle but that’s another conversation
