Dependency injection[1] is a powerful pattern that is relatively simple to implement. However, it is often overlooked—or even misunderstood—in the development of many web applications.
In .NET there is nice tool called the Unity container[2] that facilitates the use of dependency injection. There are a few different ways in which dependency injection can be applied. This post will focus on injecting dependencies via the constructor (also known as Constructor Injection).
Before looking at how the Unity container works, let's take a brief look at what dependency injection is.
What is Dependency Injection?
Let's say we have a PizzaServiceController class with the following constructor:
public PizzaServiceController()
{
_pizzaRepository = new PizzaRepository();
_presenter = new PizzaPresenter();
}
In the above snippet of code, the PizzaRepository object is the dependency because PizzaServiceController depends on it in order to carry out some behavior. However, PizzaServiceController now has a hard dependency on a concrete implementation of an object. This has the likelihood of creating a great deal of pain for us as the requirements of our application change. What would we do if we wanted to use a different repository instead of the PizzaRepository? Our hands would be pretty tied because we would then need to find all of the places where it was being used and change it to the new one. In a small application, this might not be so bad. But, in a large one, this could be a painful change to make. We can avoid those potential headaches by injecting it:
public PizzaServiceController(IRepository repository, IPizzaPresenter presenter)
{
_repository = repository;
_presenter = presenter;
}
So, we see here that "injecting the dependency" is just a fancy way of saying "passing the dependency to the object." In this example we've modified the PizzaServiceController constructor to accept the dependency as an argument—hence "constructor injection."
With this change, we now need to create an instance of the repository somewhere in order for us to be able to pass it in. This could be done in Main if it were a desktop application. But, where do we instantiate objects in a web application? In a typical MVC web application, this will happen in the controllers. But, since there are always multiple controllers—each with dependencies of their own—we still need a solution for resolving these dependencies in one area.
Enter the Unity Container
In very simple terms, the Unity container will allow you to register a set of mappings to specify what concrete type should be passed in when it instantiates objects that have any of the registered dependencies. For example, in your Global.asax, you would include the following:
var container = new UnityContainer();
container.RegisterType<IRepository, PizzaRepository>();
container.RegisterType<IPizzaPresenter, PizzaPresenter>();
container.Resolve<PizzaServiceController>();
At runtime, the Unity container will instantiate PizzaServiceController because it is specified in Resolve. Then it will create an instance of PizzaRepository and inject it into the constructor of PizzaServiceController on our behalf due to the fact that the signature specifies that we need an object that is an IRepository. As a nice benefit, it will also dispose of the PizzaRepository that it created when the PizzaServiceController becomes eligible for garbage collection. There are also a host of other options that provide for greater control over the lifecycle of the objects it instantiates.
What makes this useful?
For applications that grow and change, the use of dependency injection helps us keep our code loosely coupled, and therefore easier to change. The Unity container helps us manage the instantiation and disposal of dependencies while allowing us to focus on creating a more maintainable application.
References and Resources
[1] Inversion of Control Containers and the Dependency Injection pattern by Martin Fowler