John Bennett's blog » dependency-injection

What is dependency injection?

John — Mon, 16 Feb 2009 22:29:00 +0000

[I recently wrote this up for some folks at work, and thought it was worth re-posting here.]

Dependency injection is a hot topic these days. You hear terms like “dependency injection”, “inversion of control”, “IoC container”, “DI container”, etc. a lot. But like with “SOA”, people tend to define the terms however suits them. I’m going to do the same.

The first thing I want to do is distinguish between dependency injection and a container. Dependency injection is a pattern. You don’t need any software tools other than your favorite language and compiler to “do dependency injection.” The dependency injection pattern is a subcategory of the inversion of control (IoC) pattern. A lot of people use DI and IoC interchangeably, and that’s fine with me, as DI is by far the most common type of IoC.

An container is a software tool. Examples of .NET IoC/DI containers are Spring.NET, StructureMap, Castle Windsor, Autofac, and Unity (part of Enterprise Library). While all of these have their own unique bits of functionality, they have a large overlap in that they are all container implementations.

An analogy: You’ve probably heard of the Repository design pattern for data access. And you’ve probably heard of object-relational mapping (ORM) tools like NHibernate, LLBLGen Pro, Linq to SQL and Entity Framework. The relationship between them is analogous to the relationship between the dependency injection design pattern and IoC container implementations: If you’re using the design pattern, the tool makes life easier for you. But it’s entirely possible to use the pattern without using the tool.

So what is the dependency injection design pattern?

Let’s start with the problem. Most classes have to collaborate with other classes in order to fulfill their responsibilities. But having one object instantiate another creates a hard dependency that can limit flexibility, testability, and transparency to consuming developers.

Let’s write some code for a big important Boss who asks her Gopher to go get lunch:

public class PizzaService
{
    public string DeliverFood()
    {
        return "Large pepperoni.";
    }
}
  
public class Gopher
{
    public string GetLunch()
    {
        var pizzaService = new PizzaService();
        return pizzaService.DeliverFood();
    }
}
  
public class Boss
{
    public void HaveLunch()
    {
        var gopher = new Gopher();
        var myLunch = gopher.GetLunch();
        this.Eat(myLunch);
    }
  
    private void Eat(string food)
    {
    }
}

One big problem with this code is that the only thing the Boss can ever have for lunch is pizza. Another drawback to this code is that Gopher’s dependency on PizzaService is opaque and hidden. The only way to know there is a dependency is to open up the code of the Gopher class and read it. It doesn’t appear anywhere in the constructor or method signatures. We want as much as possible to be obvious and explicit. We don’t want developers using our APIs to have to sift through our code to figure out all the dependencies.

We can start to address the first concern by creating an ILunchService interface:

public interface ILunchService
{
    string DeliverFood();
}
  
public class PizzaService : ILunchService
{
    public string DeliverFood()
    {
        return "Large pepperoni.";
    }
}
  
public class Gopher
{
    private ILunchService lunchService;
  
    public Gopher()
    {
        lunchService = new PizzaService();
    }
  
    public string GetLunchForTheBoss()
    {
        return lunchService.DeliverFood();
    }
}

But we still have the same problem of pizza every day, because the Gopher is still creating the instance of PizzaService. Even if the Boss is a real pizza fanatic, we can’t unit test Gopher without actually having a pizza made and delivered. That could get pretty expensive.

In more real-world terms, we can’t write tests without creating and accessing real instances of expensive resources (like a database). That means the unit tests will be slow, and that’s very bad. We want to run hundreds or thousands of unit tests in a few seconds. Even with larger, slower integration tests we don’t actually want to have hundreds of pizzas delivered when our automated test suite runs every night…

And we also haven’t addressed the opaque dependency of Gopher on PizzaService.

So the next step is for the Gopher to require that somebody tell him what kind of lunch service to use. (This isn’t the most proactive gopher in the company.)

public class Gopher
{
    private ILunchService lunchService;
  
    public Gopher(ILunchService lunchService)
    {
        this.lunchService = lunchService;
    }
  
    public string GetLunch()
    {
        return lunchService.DeliverFood();
    }
}

At this point, we are using the dependency injection pattern in the Gopher class. Specifically, we are using constructor injection. That is, in our constructor, we are asking for someone to pass in (inject) an instance that we depend on. That’s all dependency injection is. Big words, simple concept. We’ve inverted the usual way things are done. Gopher doesn’t control how its dependencies are created, the consumer of Gopher does. “Inversion of control” is a fancy phrase for letting the consumer take control.

We could also have used property injection (setting a property value with the dependency) or method injection (passing the dependency as a parameter to a method). But the best practice is to use constructor injection for required dependencies — don’t allow someone to create an object if it doesn’t have its required dependencies fulfilled — and property injection for optional dependencies. Method injection is really only recommended when you’re adding a container implementation to an existing code base. It’s yucky (because it’s less obvious), and shouldn’t typically be used in new code.

There are two big benefits to our use of the dependency injection pattern at this point: First, the Boss can get any kind of lunch she wants by simply telling the Gopher what kind of service to use. And second, other developers who want to use the Gopher class can’t help but see that the Gopher depends on an ILunchService — you just can’t create a Gopher instance without one. This is the kind of explicit, obvious dependency we want.

But we still have a problem. We’ve made a pretty career-limiting move for the Gopher. We gave the Boss more work to do. The Boss now has to create the PizzaService in order to get lunch:

public class Boss
{
    public void HaveLunch()
    {
        var pizzaService = new PizzaService();
        var gopher = new Gopher(pizzaService);
        var myLunch = gopher.GetLunch();
        this.Eat(myLunch);
    }
  
    private void Eat(string food)
    {
    }
}

You might say “That’s only one more line of code than the Boss had before.” Well, I’ve found that giving Bosses (or developers using your API) even a tiny bit more work to do is generally a bad idea. And while we’re on the subject, why should the Boss have to create the Gopher, too? The Gopher should just be there, ready to do the Boss’s bidding. In fact, isn’t the Boss dependent on the Gopher?

Oh, wait a minute, we already know what to do with hard dependencies caused by using the new operator — we use dependency injection:

public class Boss
{
    private Gopher gopher;
  
    public Boss(Gopher gopher)
    {
        this.gopher = gopher;
    }
  
    public void HaveLunch()
    {
        var myLunch = gopher.GetLunch();
        this.Eat(myLunch);
    }
  
    private void Eat(string food)
    {
    }
}

We’ve applied the dependency injection pattern to the Boss, too, and another dependency (of Boss on Gopher) has been dragged into the light of day for all to see. In this case we haven’t created an IGopher interface, but that’s okay. Sometimes you don’t need to use an interface (although often you should). With or without an interface, developers using the Boss class now have a much clearer picture of what’s going on — without digging into the actual code. Everything is explicit and obvious.

You might start to wonder whether some objects that do a lot of things are going to have 10 constructor parameters. Well, yes. But that’s a code smell: if you have an object with that many dependencies, it’s probably doing too much. It’s very likely that it has multiple responsibilities, and your classes should typically adhere to the Single Responsibility Principle as much as possible. Split that class into several that each does one thing only. This makes your software easier to change, too. Smaller, simpler classes mean each class has fewer reasons to change, and fewer collaborators means fewer potential ripple effects when you do make changes.

Here’s one of the big ideas behind dependency injection: separating the object graph from the execution graph. In code where you see new Foo() all over the place, the object graph and the execution graph are tightly intertwined. That’s usually a bad thing, because objects rarely reference each other in the exactly the same hierarchical structure that they call each other’s methods. Testing or changing a little thing in that kind of code can be a real pain.

A common solution for separating object graph creation from the execution graph is to use factory classes. The Abstract Factory pattern is one of the older and better known design patterns. All of the instantiation and injection of the dependencies would happen in the factories, out of the way of your executing business logic.

public static class BossFactory
{
    public static Boss GetBoss()
    {
        return new Boss(new Gopher(new PizzaService()));
    }
}

In this code, the boss is still having pizza every day for lunch, but it’s easy to imagine how we could use configuration or a UI input value to select a different implementation of ILunchService each day. The key is that the selection of that implementation doesn’t really have anything to do with the process of actually having lunch. And now our code separates those two processes very cleanly.

Further reading on dependency injection:

Dependency Injection Demystified by James Shore
Dependency injection on wikipedia
Misko Hevery’s blog, especially

Removing dependencies between controllers and Linq DataContext classes with dependency injection

John — Sat, 22 Dec 2007 15:30:00 +0000

In ScottGu’s most recent post on ASP.NET MVC, he demonstrates using a partial class for the NorthwindDataContext created by the Linq to Sql designer. In the partial class he creates some simple wrapper methods for the ProductsController to use when retrieving and persisting data. However, the ProductsController is still tightly coupled to NorthwindDataContext. Let’s decouple them using an interface and some dependency injection…

If you want to follow along, you’ll need to download ScottGu’s sample, which I’ll use as my starting point. The sample (MvcApplication5) uses the MvcToolkit, but I found I had to download MvcToolkit and repair the reference to before I could successfully build and run the sample.

Creating the IProductsRepository interface

The first step is to create an IProductsRepository interface. We’ll use VS2008′s refactoring support to extract an interface from Scott’s NorthwindDataContext partial class. Open that file in the editor, right-click on the partial class declaration and choose Refactor > Extract Interface.

Name the interface IProductsRepository and select just the five methods that Scott added in the partial class.

That will create IProductsRepository.cs in the Models folder with the new interface.

It also adds the interface to the NorthwindDataContext declaration. Now we can go to the ProductsController in the Controllers directory and change the northwind field to be of type IProductsRepository.

At this point, we have a problem. Both the Create() and Update() action methods call SubmitChanges() on the data context. When we try to build, the compiler tells us that the SubmitChanges method isn’t part of the IProductsRepository interface. The whole goal here is to reduce the coupling between the controller and the Linq-generated DataContext. So we’re going to move the Linq code into the partial class and access it through the interface we just created.

Let’s start with Create(). Create() calls AddProduct() on the data context, which looks like this:

Let’s add a call to SubmitChanges() to AddProduct():

We have to remove SubmitChanges() from Create():

There is no method in our IProductsRepository interface that the controller can call when updating a product, so we’ll create a SaveProduct() method in the interface and implement it in NorthwindDataContext. The only thing our implementation of SaveProduct() will do is call SubmitChanges(). So Update() looks like this:

And SaveProduct() like this:

Setting up for dependency injection with Windsor

At this point, everything works as before, we’ve just added an interface and moved some calls to SubmitChanges(). ProductsController and NorthwindDataContext are still tightly coupled. For the next part, we’re going to use dependency injection and our new interface to break the coupling. For some background on dependency injection and why you might want to use it, see this article and links by James Shore.

There are a number of tools that will do dependency injection for you. We’re going to use Windsor from the Castle Project. We’ll also use MvcContrib, a community-driven project on CodePlex that is developing useful add-ons to ASP.NET MVC. One of those add-ons is a WindsorController, which allows us to easily use dependency injection on our controllers.

You’ll also need to download the latest release of the MvcContrib project. I’m using the beta version 0.0.1.32 in this sample. We need to add a couple of references to the MvcToolkit assemblies. When you download the binaries version, you’ll have a bin directory with the assemblies and a Samples directory with some code that we’ll use below.

Add references in MvcApplication5 to:

Castle.Core.dll
Castle.MicroKernel.dll
Castle.Windsor.dll
MvcContrib.dll
MvcContrib.Castle.dll.

Now we need to modify our Global.asax.cs file so that our web application automatically creates a Windsor Container. All of these changes are below are also shown in the sample app provided in the MvcContrib download.

Add using statements for the Castle.Core and Castle.Windsor namespaces.
Implement the IContainerAccessor interface, which has a single property named Container.
Add a static field to hold the container, and a static property to wrap it.

Here’s what they look like so far:

Next up is to instantiate the container and make it aware of all the controller classes in our application. This is done by looking for all types in the current assembly that can be cast to the IController interface.

Add a using statement for the MvcContrib.ControllerFactories namespace.
Copy in the InitializeWindsor() method from the sample app.
Refactor the route handling setup from Application_Start() to a separate method named AddRoutes().
Change the Application_Start() handler to call InitializeWindsor() and AddRoutes().

The end result in Global.asax.cs is:

Two changes to the sample code are required. The first change is to tell the WindsorContainer to use the web.config file to get the configuration values. We’ll go into the config settings in the next section. Here all we need to do is pass into the WindsorContainer constructor a new XmlInterpreter(). This tells the container to use the current app.config or web.config file.

The sample uses a controller class named WindsorController to get access to the assembly containing all the controllers. Since we don’t have a WindsorController type, our second change is to:

Add a using statement for the MvcApplication5.Controllers namespace.
In the InitializeWindsor() method (line 42 in the screenshot) change “typeof(WindsorController)” to “typeof(HomeController)”. I use HomeController, since most ASP.NET MVC applications will have one of those.

After these changes, the two lines in InitializeWindsor() look like this:

Injecting the repository into ProductsController

Getting back to our ProductsController class, remember that we changed the northwind field to be of type IProductsRepository, but we still populated it with an instance of NorthwindDataContext. What we want is for ProductsController to know nothing about NorthwindDataContext. Any class that implements IProductsRepository should work just fine for retrieving and saving products.

First, we’ll remove the assignment of the NorthwindDataContext instance. While doing this, we’ll change the field name from “northwind” to “repository” to make it more generic. VS2008′s refactoring support makes this a breeze. Then we’ll add a constructor that takes a parameter of type IProductsRepository. (Make sure the IProductsRepository interface is declared as public, since we didn’t do that earlier.) The result is:

We’re now ready to tell Windsor: “Whenever you create a ProductsController, pass a NorthwindDataContext into its constructor.” We do that through a config section in web.config. First declare a section for castle in the element and add a element as follows:

What we’re telling Windsor here is that whenever a controller has a constructor parameter of type IProductsRepository, give it a new instance of NorthwindDataContext.

At this point, we can run the application to see that it all works just like it did in Scott’s original version. The difference now is that our controller and data context are no longer tightly coupled. If we wanted to change from Linq to some other ORM tool, or to move the Products table to a different Linq data context class than the rest of Northwind, before we’d have to make a bunch of code changes. Now all we have to do is update our web.config file to point Windsor at a class that implements IProductsRepository and we’re done.

Enjoy. And please comment on what’s confusing, what I glossed over too quickly, and what I spent too much time explaining. I’m still getting the hang of this and welcome any suggestions.