Disclaimer: This is a series of posts in which we’ll go through the IoC’s that are used in today’s applications
The most simple answer I can give you is this:
It’s an abstraction over Factory Method.
It helps, in my opinion to think of this as a factory method, because then you know what to expect of it, since it constructs/resolves a specific implementation based on the configuration you provide it.
In a factory method you write, aka “hard code”, the implementation you will be using. In an IoC container you basically do the same except it’s easier to change, if you write it in the xml file since using it in code leaves you with what you started and never got to changing it.
However, an IoC has an additional plus over the hand coded factory, that is “It is able to construct objects based on the configuration you supplied”.
Does it help ?
Oh yes it helps. There’s a principle in software that states “High level modules should not depend on low level modules, both should depend on abstractions”. And guess what the principle I just stated is the Dependecy Injection Principle, it is an important point to note since IoC containers are often referred to as Dependency Injectors. So you will probably find the IoC/DI whenever reading about an IoC.
With the help of an IoC you can declare dependencies of you object using abstractions, usually in the form of interfaces and/or base classes.
In the next part will explore a couple of IoC’s that the .NET has to offer as well as from the outside of the .NET ecosistem.
I hope that by the end of this series we can form a summary of benefits and deduct some ground rules for choosing a certain IoC, or deciding if we need it.