Expect everything to change...

Introduction

Inversion of Control (IoC) and Dependency Injection (DI) are two related practices in software development which are known to lead to higher testability and maintainability of software products.

At a glance, these patterns are said to be based on the Hollywood Principle, which states: "don't call us, we'll call you". With a canonical approach, you hard code the classes of the objects you want to instantiate in the source of your application, supply parameters to their constructors and manage their interactions. Each object knows at compile time which are the real classes of the objects they need to interact with, and they will call them directly. So, under this point of view, you and your objects are the ones calling Hollywood. To invert this approach, you need some support from a framework which makes your application smart enough to guess which objects to instantiate, how to instantiate them and, in general, how to control their behavior. Instead of working with concrete classes you'll work with abstractions like interfaces or abstract classes, letting your application decide which concrete classes to use and how to satisfy their dependencies on other components.

Creating a simple web page scraper

Following the requirements of the sample application let's write a class capable of satisfying them. It's called HtmlTitleRetriever, and exposes a single method called GetTitle, which accepts the Uri of a file and returns a string with the title of the HTML document -if it has one- or an empty string.
view sourceprint?

public class HtmlTitleRetriever
{
    public string GetTitle(Uri file)
    {
        string fileContents;
        string title = string.Empty;

        WebClient client = new WebClient();
        fileContents = client.DownloadString(file);

        int openingTagIndex = fileContents.IndexOf("<title>");
        int closingTagIndex = fileContents.IndexOf("</title>");

        if(openingTagIndex != -1 && closingTagIndex != -1)
            title = fileContents.Substring(openingTagIndex, 
                closingTagIndex - openingTagIndex).Substring(7);

        return title;
    }
}

What this class does is very simple. First it instantiates a WebClient object - a facade to ease use of HttpWebRequest and HttpWebResponse classes. Then it uses the object to retrieve the contents of the remote resource, using the HTTP protocol. Using string routines, it looks for the opening and closing title tags and extracts the text between them.

At this point you might be wondering what's so wrong in this class to imply the need for a different approach in implementing its requirements. Actually, not much, as long as the requirements remain so simple. But from a more general point of view there are at least two aspects which need to be revisited about this implementation:

• The class does more than it should do. A principle of good system design is SoC - separation of concerns. According to this principle, a software component should be able to do a simple task only, and do it well. Instead, the class first downloads the file from the web, and then applies some sort of parsing to retrieve the contents it cares about. These are two different tasks, which should be separated into two different components.
• What if the class needed to be able to retrieve documents not accessible via the HTTP protocol? You'd need to change the implementation of the class to replace or add this feature. The same consideration applies to the parsing process. In this example it doesn't make much sense but you may discover that under certain circumstances adopting a different scraping mechanism would lead to better performance. In other words, the class has deep knowledge - read, dependencies - on concrete implementations of other components. It's better to avoid this because it leads to bad application design.

Components and Services

"A component is a small unit of reusable code. It should implement and expose just one service, and do it well. In practical terms, a component is a class that implements a service (interface). The interface is the contract of the service, which creates an abstraction layer so you can replace the service implementation without effort."

Applying SoC with Components and Services

So far you've seen that the responsibilities of the HtmlTitleRetriever class can -and should- be separated into two classes: One for retrieving files and one for parsing their contents.
Note that these are generic jobs, in that they can be implemented in several ways. The implementation above is just one of the available choices, but you can think of retrieving files from other mediums, as well as adopt a different mechanism to extract the contents of the title tag. In other words, these tasks are supplied by a service, which can be carried out in several ways. The concrete classes which perform the task are the components. The file downloading and title scraping service' contracts can be defined via interfaces, IFileDownloader and ITitleScraper.

public interface IFileDownloader
{
    string Download(Uri file);
}

public interface ITitleScraper
{
    string Scrape(string fileContents);
}

Now let's implement these services with concrete classes - the components - supplying the same features as the original HtmlTitleRetriever class.

public class HttpFileDownloader : IFileDownloader
{
    public string Download(Uri file)
    {
        return new WebClient().DownloadString(file);
    }
}

public class StringParsingTitleScraper : ITitleScraper
{
    public string Scrape(string fileContents)
    {
        string title = string.Empty;
        int openingTagIndex = fileContents.IndexOf("<title>");
        int closingTagIndex = fileContents.IndexOf("</title>");

        if(openingTagIndex != -1 && closingTagIndex != -1)
            title = fileContents.Substring(openingTagIndex, 
                closingTagIndex - openingTagIndex).Substring(7);

        return title;
    }
}

These components completely satisfy the requirements of the application. Now they need to be assembled to provide the downloading and parsing services together. So let's modify the original awful class to benefit from their features. This time the class mustn't be aware of the concrete implementation of the services. It just needs to know that someone will provide those services and it will simply use them. The new HtmlTitleRetriever class now looks like this:

public class HtmlTitleRetriever
{
    private readonly IFileDownloader dowloader;
    private readonly ITitleScraper scraper;

    public HtmlTitleRetriever(IFileDownloader dowloader, ITitleScraper scraper)
    {
        this.dowloader = dowloader;
        this.scraper = scraper;
    }

    public string GetTitle(Uri file)
    {
        string fileContents = dowloader.Download(file);
        return scraper.Scrape(fileContents);
    }
}

Approaching IoC and DI

Managing objects creation and disposal using IoC and DI requires actually less magic than I pretended to make you believe. So, who is going to deal with objects if you are no longer in charge for it?

The main point of a framework which offers IoC and DI is a software component called container. As its name implies, the container will achieve knowledge about components needed by your application to run and will try to be smart enough to understand which component you want. This happens when you query it asking to return an instance of one of the components it contains. This is what IoC means in practice; you'll no longer instantiate classes using constructors, but instead register them into the container and then ask it to give you one instance of a component.

The other fundamental feature of the container is that it will be able to resolve-and inject-dependencies between your objects; hence the name Dependency Injection. In the sample application, the container will be smart enough to guess that in order to instantiate an HtmlTitleRetriever object, it needs to instantiate components supplying the IFileDownloader and ITitleScraper services.

Castle Windsor Container

Even though the MicroKernel provides enough features for this simple example, Windsor Container is usually more suitable for applications which require a more flexible approach to container configuration and a more user friendly API. The snippet below shows how to configure the sample application with Windsor Container.

IWindsorContainer container = new WindsorContainer();

container.AddComponent("HttpFileDownloader", typeof(IFileDownloader),
     typeof(HttpFileDownloader));
container.AddComponent("StringParsingTitleScraper", typeof(ITitleScraper),
     typeof(StringParsingTitleScraper));
container.AddComponent("HtmlTitleRetriever", typeof(HtmlTitleRetriever));

HtmlTitleRetriever retriever = container.Resolve<HtmlTitleRetriever>();

string title = retriever.GetTitle(new Uri("some uri..."));

container.Release(retriever);

As you can see, the API is very similar. That's because Windsor is not another container, but it's built on top of the MicroKernel and simply augments its features. One small but useful feature to note is that Windsor lets you retrieve components using generics, thus avoiding casts.
So far, you've seen how to configure the container programmatically. In a real life application, you would need to write a lot of code for container configuration. Changing something would require a new build of the entire solution. Windsor offers a new feature which lets you configure the container using XML configuration files, much like you would do with a standard .NET application. So let's rewrite the code above to benefit from external configuration.

First you need to create a configuration file, called App.config or Web.Config, depending on the kind of application you're building. Note that Windsor has the ability to read configuration from other locations as well. The default application configuration file is just one of the options.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

  <configSections>
    <section name="castle"
        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, 
          Castle.Windsor" />
  </configSections>

  <castle>
    <components>
      <component id="HtmlTitleRetriever"
                 type="WindsorSample.HtmlTitleRetriever, WindsorSample">
      </component>
      <component id="StringParsingTitleScraper"
                 service="WindsorSample.ITitleScraper, WindsorSample"
                 type="WindsorSample.StringParsingTitleScraper,
                      WindsorSample">
      </component>
      <component id="HttpFileDownloader"
                 service="WindsorSample.IFileDownloader, WindsorSample"
                 type="WindsorSample.HttpFileDownloader, WindsorSample">
      </component>
    </components>
  </castle>
  
</configuration>

First, the section handler for Windsor configuration has to be registered into the configSections section.Then, the actual configuration takes place into the castle section and is very similar to what I did before via code. The syntax is the following:

• id (required): a string name to identify the component
• service: the contract implemented by the component
• type: the concrete type of the component

Service and type attributes require the full qualified name of the type (namespace.typename) and the assembly name after the comma.

You may have noticed that the HtmlTitleRetriever class is registered without supplying a service. In fact, it doesn't implement any interfaces nor base class, since it's unlikely that you will ever provide a different implementation of it. The other two components, instead, are concrete implementation of a service that can be carried out in several ways. This syntax lets you register more than one component for the same service. By default, when the container finds that two components have been registered for the same service, it resolves dependencies by supplying the first component registered-either in the configuration file or via code-but this behavior can be changed using the string identification key of the component. Here's how the code of the application changes to take advantage of external configuration:

IWindsorContainer container = new WindsorContainer(new XmlInterpreter());
HtmlTitleRetriever retriever = container.Resolve<HtmlTitleRetriever>();
string title = retriever.GetTitle(new Uri("some address..."));
container.Release(retriever); 

Taking advantage of IoC and DI

So far you've seen how to switch from a canonical programming process to inversion of control. Now let's make a small step towards understanding why IoC makes applications better.
Suppose that the original requirements changed and you needed to retrieve files no longer using the HTTP protocol but instead via FTP. With the former approach you'd need to change the code into the HtmlTitleRetriever class. That's not a lot of work since the example is very simple, but in an enterprise application this may imply a lot of work. Instead, let's see what it takes to provide this feature using Windsor.
First, you'll need to create a class implementing the IFileDownloader interface which retrieves files via FTP. Then, register it into the configuration file, replacing the former HTTP implementation. So, no need to change a single line of code of the application, and no need for a recompilation since you can provide this new class into a new assembly. Actually, the features provided by Windsor are much smarter than this, but this is topic for another article.

Summary

In this article you've seen what Inversion of Control and Dependency Injection are and how they can lead to a better design of a software application. You've seen how to take advantage of them using the open source Windsor Container which comes along with Castle Project.


My thanks to: http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart1.aspx