Why do I need an Inversion of Control Container?
You may have come across the term ‘Inversion of Control Container’ (IoC container), it’s become a hot topic in discussions on .NET application architecture. The term ‘IoC container’ sounds quite scary, but the basic concept is simple. It is all about building component oriented software; software that can be re-wired simply with configuration.
Before I introduce IoC containers, there’s an essential building block we have to understand: Dependency Injection. It’s another scary sounding concept, but it really is very straightforward. First an example using a class
Reporter that gets reports and then sends them:
public class Reporter
{
....IReportBuilder _reportBuilder;
....IReportSender _reportSender;
....public Reporter(IReportBuilder reportBuilder, IReportSender reportSender)
....{
........_reportBuilder = reportBuilder;
........_ reportSender = reportSender;
....}
....public void SendReport()
....{
........Report report = _reportBuilder.CreateReport();
........_reportSender.Send(report);
....}
}
Rather than creating instances of classes directly inside
Reporter using the ‘new’ operator, we are injecting our dependencies by passing anything that implements
IReportBuilder and
IReportSender to
Reporter’s constructor. Our software can decide what these classes will be after compilation. This is where the IoC container comes in. An IoC container is a very smart factory that knows how to create your class and its dependencies. We simply register our components and the interfaces they implement with the container. For example, stating that when we ask for an
IReportSender we should be given an
EmailReportSender. Remember components are simply classes written using the Dependency Injection pattern show above. The IoC container uses reflection to examine the signature of
Reporter’s constructor and then looks up the components it needs in its configuration.
Now when we need a reporter we can simply get it from the container by writing:
Reporter reporter = container.Resolve<Reporter>();
The container will automatically resolve Reporter’s dependencies for us, supplying the implementation of
IReportBuilder and
IReportSender that we specified in the configuration. It also supplies any dependencies that the actual
IReportBuilder or
IReportSender implementation might have; it wires up our entire object graph for us.
Now, what if I want to use
SmsReportSender rather than my existing
EmailReportSender throughout my application? I only have to change the one configuration entry, rather than searching through my entire application looking for every place where a new instance of
EmailReportSender is instantiated.
You could write your own IoC container but it makes more sense to use one of the existing IoC containers for .NET, the best known is
Windsor from the Castle Project.
Dependency Injection and IoC containers are based on simple concepts, but can yield a wide range of optimisations.
Decoupling our software in this way means that we can write applications as a collection of components which can be tested and maintained independently. This is especially optimal with large enterprise systems. The ability to swap components in and out of an application without re-compilation is also extremely powerful.
I hope I’ve been able to spike your interest with this short article. I have posted a list of
further reading on my blog if you would like to find our more.
Mike Hadlow
Results from last poll:
What type of software development work are you doing currently?
27% Developing a brand new application
27% Developing a new version of an existing application
18% Developing a new module/subsystem for an existing application
15% Maintaining an existing application – bug fixes, minor changes etc
5% Migrating an existing application (e.g. Oracle to SQL, VB6 to .NET)
1% I do not develop applications
5% I do develop applications but right now I am not
2% Other
Question of the fortnight
How active are you with Open SourceSoftware?
Open Source software is increasingly popular amongst windows developers including software from http://www.codeplex.com. How involved are you?
1. I contribute to an Open Source project
2. I contribute to several Open Source projects
3. I plan to contribute to Open Source projects in the future
4. I don't contribute but I regularly use Open Source software
5. I never/rarely use Open Source software
To take part in this week’s poll question please visit
my blog to submit your answer.
