We seem to be an industry enamored with buzz words. Even though XmlHttpRequest has been around since the mid-90s, mainstream programmers didn’t give it a second thought until someone attached the term AJAX to it. The same is true for the never-ending quest to put as many different words as we can in front of “driven-development.” Another term that hit the scene in recent years is dependency injection.

Bringing form to concepts that had been around for a while, dependency injection (also known as DI) didn’t kick into full force until Martin Fowler wrote his famous article in 2004. The development community grabbed onto the term and ran with it as the next big thing we should all be doing, which is great - except for the fact that DI seemed to be only a small part of what the community as a whole was doing.

DI is an approach to providing one type with instances of the other types on which it may depend, all while keeping the types decoupled from one-another through the use of interfaces. Though defined in Wikipedia as “an approach to testing computer programs,” it’s more than just testing. That said, testing is an extremely good and important reason to use DI, because with it, you can write decoupled components, making it an integral part of good software testing. DI is a form of Inversion of Control and is sometimes confused as being the exact same thing. (Inversion of Control is a software principle whereas control of a class’ initialization and execution is delegated to another class, sometimes a container or a manager.) DI is a slight subset of Inversion of Control.

Before digging into how implementations of DI work and how to use the DI Container, you need to understand the concept of coupled and decoupled software; the former being bad and the latter being the good that becomes even better with DI.

Software Coupling

When writing software, it’s always a good idea to separate the concerns of the types involved. Separation of concerns means that each type has either only one, or a very small set of responsibilities. Of course, if you translate your software to the line of business for which it’s built, it immediately becomes apparent that a business process involves many steps and therefore many types.

Most of the time, there is a need for one type to work hand-in-hand with another and perhaps become a sub-part of another. In other words, one class may depend on another. In fact, the parent type would very likely contain an instance of the type on which it depends, usually passed in through a constructor or a property.

The problem is that this creates a coupling between the two types. Not only can the parent type not exist (or compile) without the dependent type, it can be stuck with the way that type wants to do things. I’ll show you what I mean with an example of what not-to-do, and then I’ll show you techniques for solving the problem.

A Coupled Example

Let’s take a look at a great example of a business process that can be subdivided easily: e-commerce. Among other things, three of the functions that are involved in a check-out process are:

• payment processing
• customer update
• notification

After an order is placed, a customer’s credit card must be charged, after which the customer record needs to be updated with the order he/she placed and the product purchased. Lastly, the customer should receive an email with their receipt and order summary. An additional less critical process can be logging, which can take place at every step for internal auditing purposes.

Let’s start with a type that will contain the data involved in the example. This type is called OrderInfo and can be seen in Listing 1.

To act upon this data, there’s a type called Commerce with a method called ProcessOrder, which performs all the aforementioned sub-processes. In the interest of separating the concerns, I have created types called BillingProcessor, Customer, Notifier, and Logger. Each of them might be used from another class in another situation, but it’s also a good idea not to put everything in the Commerce type to encapsulate the check-out process.

The four classes are shown in Listing 2. Notice that in the interest of simplicity, their methods have no real functionality. If they did, it would be complex and involve several resources, such as a database, the file system, or additional APIs like an email sender and a payment gateway. Also note that each of the methods of the four classes act upon different pieces of the OrderInfo type.

The Commerce type incorporates each of the other four types by receiving an instance of each in its constructor. Think of this as an orchestrator or manager class. You can see this one in Listing 3.

Assuming that you have an instance of OrderInfo with the necessary data, using the Commerce type can involve something like this:

Commerce commerce = new Commerce(
    New BillingProcessor(),
    New Customer(),
    New Notifier(),
    New Logger());
    
commerce.ProcessOrder(orderInfo);

The problem here is two-fold. First, the Commerce type is completely and utterly coupled to the other four types. Not only can it not work without them, but it’s totally locked into the implementation that each provides. What if the system you’re writing changes payment gateways in the future? If your application were written like the example snippet above, you would have to rewrite the entire BillingProcessor class, only to rewrite it again later. Of course you can have two different classes, but that would mean changing the code in the Commerce class in order to alter which new or different types gets received.

The second problem is that the Commerce class is difficult to test. Eventually you will have to test the production functionality of the four classes that house the sub-processes, but what if you want to test the ProcessOrder method of the Commerce class to see how it handles the combination of the four processes without having to deal with the resource access that those processes might undertake? Writing a unit test for this method means having to bring in all four of the other types and whatever resource access was written into them.

coupled = bad

This is “coupled” behavior, and remember coupled = bad. But I didn’t spend all that time writing code only to tell you not to do it this way. I’m going to make adjustments to the code above in order to decouple my components and make everything more extensible and testable.

A Decoupled Example

The first step to decoupling application components is to abstract out the implementation from the definition in the four process classes. This way, you can provide a production implementation and test implementation later. So the first thing to do is refactor the definition of the classes out to four interfaces, as shown in Listing 4.

Then you’ll modify the four process classes to implement their appropriate interface. In the interest of space, only the BillingProcessor class is included in this code snippet, but this same pattern applies to the other three process classes.

Public class BillingProcessor : IBillingProcessor
{
    Void IBillingProcessor.ProcessPayment(
          String customer,
          String creditCard,
          Double price)
    {
       // Perform billing gateway processing
    }
}

You can now write as many different billing processors as you want, each providing a different implementation of the interface. The key now is to modify the Commerce class so that it receives injections by way of the interfaces and not the concrete types as before. The rewrite of the Commerce class is in Listing 5.

I’ve provided the entire class again so you can see that the only thing that has changed is the type of the constructor arguments and the class fields. The method calls in the ProcessOrder method are exactly the same. The Commerce class makes these method calls and leaves their actual function to whatever the implementation classes are that were sent through the constructor. The Commerce type’s dependencies were injected through the constructor without being coupled to the Commerce type. The only coupling that took place is through the interfaces and they act as plumbing. This is good coupling.

This light coupling is DI in its simplest form. The components have been decoupled from one another and through the use of interfaces, the application can grow and change in the future and components can be swapped if and when necessary. In fact, in the context of Visual Studio projects, the Commerce class can sit in one assembly (possibly the main application), the process classes in another (or even four different ones), and both sides share a third assembly containing the interfaces.

If you were to write a unit test against the Commerce class’ ProcessOrder method, you would no longer need the production instances of the four process classes, and certainly not even a reference to the assembly in which they live. You can write test versions that implement the interfaces in a totally different way, perhaps doing nothing at all except providing a dummy return value when one is expected. In fact, ideally, you wouldn’t need to write test implementations at all but can use a mocking framework to create them on-the-fly within the unit test itself.

The one thing that hasn’t changed with this refactoring is the fact that whatever called the Commerce class still needs to instantiate the four process classes in order to inject them into the instance of Commerce. This is where a DI container will come in handy.

Dependency Injection Containers

DI containers are about two things, R&R. No, not rest and relaxation. I’m talking about registration and resolving. These are the acts of storing a list of types and later retrieving instances of them at will.

DI containers are about two things, R&R (registration and resolving)

The DI container is the tool that turns DI into architectural patterns that lets you satisfy a type’s dependencies easily and automatically. It is a repository that typically associates interfaces with concrete types.

How a DI Container Works

DI containers all work in a very similar fashion. At the beginning of an application’s execution-cycle, you need to register associations of concrete types to the interfaces that they implement. What makes containers different from one another is the way registration functionality is exposed. Later, when an instance of an interface implementation is requested, the container can offer an instance of the appropriate concrete type, called resolving. What makes the process of the instance assignment special is that it happens recursively, as many times as necessary.

At the start of an app, you might register 20 types with 20 interfaces. When you request a type from the container by specifying an interface, not only do you get an instance of the associated type, but the container offers a bit more. The container looks at either the constructor arguments or the public properties and determines whether they are interface types. If they are interface types, it attempts to resolve them as well and set the argument or property value to the instance it resolved. The container then repeats the process for each of the resolved types as well. By the time it returns the type you requested, it has all its dependencies with it, and their dependencies, and so on down the line.

Because essentially all containers work this way, there’s no better way to fully understand what goes on behind the scene than to see the code of a very simple DI container. Any container you use later, no matter how complex it may seem, is essentially a variation of what I’ll show you here.

Because you need to store associations of interfaces to concrete types, start by writing a simple class to represent this association:

Public class ContainerItem
{
    Public Type AbstractionType { get; set; }
    Public Type ConcreteType { get; set; }
}

Now it’s a matter of writing a class that will serve as the container and expose an API for adding instances of ContainerItem types. Listing 6 shows the container class.

As you can see, all the code does is expose a method called Register, which will let you store an association of an interface to a concrete type. Each association is stored in the container list, _Registrations. Now you just need to expose another method that will let you ask for whatever type is associated to a given interface. Call this method CreateType.

Public T CreateType<T>() where T : class
{
    Object instance = null;
    Type type = typeof(T);
 
    ContainerItem containerItem =
       _Registrations.Where(item =>
          item.AbstractionType.
          Equals(type)).FirstOrDefault();
    
    If (containerItem != null)
            Instance = Activator.CreateInstance(
               ContainerItem.ConcreteType);
    
    Return instance;
}

This simple version of the CreateType method looks for an item in the registration list where the AbstractionType property is equal to the type requested in the generic argument. If it finds an entry, it takes the ConcreteType property and creates an instance of it to return.

Where a DI container provides its real value is in the recursive walk it takes through the properties and/or constructor arguments of the types it resolves, in order to further resolve its dependencies. Modify the CreateType method to do just that.

You also need to return an instance of the requested type if it isn’t an interface. This way, the CreateType method can be used to instantiate a type that might not have been registered earlier, but still walk through it to resolve its dependencies. Listing 7 shows the modified CreateType method.

It doesn’t take a lot of code to take the type that is found in the list, go through the arguments of its constructor and if they are of an interface type, attempt to resolve them. You continue to do the same for those types, and so on until the type initially requested is returned.

In order to use this simple container, modify the e-commerce code snippet I wrote back in the “A Coupled Example” section. The Commerce class will remain exactly the same, as will the interfaces and the four processes. Only the client must change.

Container container = new Container();
    
container.Register<IBillingProcessor,
                   BillingProcessor>();
container.Register<ICustomer, Customer>();
container.Register<INotifier, Notifier>();
container.Register<ILogger, Logger>();
 
OrderInfo orderInfo = new OrderInfo()
{
    CustomerName = "Miguel Castro",
    Email = "miguel@dotnetdude.com",
    Product = "Laptop",
    Price = 1200,
    CreditCard = "1234567890"
};
 
Commerce commerce = container.CreateType<Commerce>();
    
commerce.ProcessOrder(orderInfo);

Keep in mind that in a real application, the registrations occur at startup and container is saved in a way that it can be accessed from anywhere. If any of the registered types were to also have interface-based constructor arguments, they would be resolved also, provided those interfaces were registered in the container.

Any container you decide to use works in a very similar fashion to what I’ve just demonstrated. There are many DI containers for you to choose from, according to your needs.

A Quick Tour Though Some Popular DI Containers

Although this article is not a tutorial on all the available DI containers out there, it’s worth talking briefly about a few of them and showing some simple examples.

Unity is Microsoft’s answer to the call for DI containers. It works in a very similar fashion to the make-shift container you looked at in this article. In fact, the only difference you’ll note is the name of the container type and the names of the methods used to register and resolve. Here’s the same container-usage example I used earlier, but using Microsoft Unity instead:

UnityContainer container = new UnityContainer();
    
container.RegisterType<IBillingProcessor,
                       BillingProcessor>();
container.RegisterType<ICustomer, Customer>();
container.RegisterType<INotifier, Notifier>();
container.RegisterType<ILogger, Logger>();
 
OrderInfo orderInfo = new OrderInfo()
{
    CustomerName = "Miguel Castro",
    Email = "miguel@dotnetdude.com",
    Product = "Laptop",
    Price = 1200,
    CreditCard = "1234567890"
};
    
Commerce commerce =
   container.Resolve<Commerce>();
    
commerce.ProcessOrder(orderInfo);

Other popular containers include Castle Windsor, MEF, NInject, StructureMap, and Spring.NET. Each offers slightly different features than the others, but they all offer a way to register types and to resolve them and their dependencies. To keep the article short, and because they are very similar, details of these other containers won’t be covered here. The difference in usage scenarios is purely syntactical and there are plenty of resources available online to show you how to use them. I will demonstrate an example using one of them: Castle Windsor.

Here’s Castle Windsor. In the interest of space, I’ll leave out the creation of the OrderInfo class:

WindsorContainer container = new
WindsorContainer();
    
container.Register(Component.For<Commerce>());
container.Register(
   Component.For<IBillingProcessor>().
   ImplementedBy<BillingProcessor>());
container.Register(Component.For<ICustomer>().
                   ImplementedBy<Customer>());
container.Register(Component.For<INotifier>().
                   ImplementedBy<Notifier>());
container.Register(Component.For<ILogger>().
                   ImplementedBy<Logger>());
 
Commerce commerce =
   container.Resolve<Commerce>();
    
commerce.ProcessOrder(orderInfo);

As you can see, the process is the same, although the API exposed by Castle Windsor is very different from that of Unity. Notice that when using this container, any class to be resolved needs first to be registered, including the Commerce class, and notice that this class is registered on its own and not associated to any interface.

Let’s look at one more by seeing what the syntax for NInject looks like:

IKernel container = new StandardKernel();
    
container.Bind<IBillingProcessor>().
          To<BillingProcessor>();
container.Bind<ICustomer>().To<Customer>();
container.Bind<INotifier>().To<Notifier>();
container.Bind<ILogger>().To<Logger>();
 
Commerce commerce = container.Get<Commerce>();
    
commerce.ProcessOrder(orderInfo);

Microsoft provides another container called the Managed Extensibility Framework, or MEF. Although many will argue that MEF is not really a DI container, including Microsoft themselves, it does provide the ability to serve as one; and quite well. MEF provides the ability to develop plug-ins and extensible applications in a simple and consistent manner. It provides a container class that stores registrations as well as the ability to resolve types and dependencies: the essence of a DI container.

What makes MEF very unique is its ability to “discover” types instead of forcing you to list registrations through code at application startup. MEF lets you decorate types to be registered and associate them with an interface in that decoration. It can then go out and discover said types by building a catalog, which it can do in a number of ways. Let’s take a look at how types are registered in MEF:

[Export(typeof(IBillingProcessor))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class TestBillingProcessor
   : IBillingProcessor
{
    void IBillingProcessor.ProcessPayment(
       string customer, string creditCard,
       double price)
    {
        // perform billing gateway processing
    }
}

A class’ dependencies, as in the case of the Commerce class, need to be marked in MEF. This can be done with either the ImportingConstructor attribute for constructor injection, or with the Import attribute for property injection. The MEF version of the Commerce class is in Listing 8.

Note that the Commerce class is also exported. Later, when resolved through the container, MEF examines the attributes to satisfy its dependencies.

In order to register the necessary types, you need to create a catalog of types. MEF provides several ways of cataloging types but the easiest is the assembly catalog. This allows you to point to an assembly and let MEF scan it for types that offer type-export decorations. You can also combine more than one catalog using an aggregate catalog. In this example, you create an aggregate catalog but only add one assembly catalog to it.

AggregateCatalog catalog =
   new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(
   Assembly.GetExecutingAssembly()));
Container = new CompositionContainer(catalog);

The CompositionContainer class is MEF’s DI container. Here, I built a catalog from the current assembly, which is where the Commerce class and the four process classes reside. Later, to resolve the Commerce class and its dependencies, I used the GetExportedValue method like this:

Commerce commerce =
   Container.GetExportedValue<Commerce>();
commerce.ProcessOrder(orderInfo);

MEF is included with.NET Framework and its discovery mechanism gives it a nice quality over other containers. The trade-off is that your type registrations are scattered throughout all your classes in the way of attribute decorations. I personally do not consider this a negative thing. I like explicit code and MEF’s attribute model allows me to always know if a class is being used by MEF or not. This is something I would not be able to tell if I were using a different DI container.

Practical Application of Dependency Injection and Containers

Now, for the fun part. All of this would just be cool code if you don’t know how to apply it in your applications. I’m going to show you how to implement a DI container into three types of applications: WPF, WebForms, and MVC. With a little effort, you can modify the WPF example to work in a Silverlight scenario as well as a Metro app scenario.

The other two examples both apply to ASP.NET, but I’ll provide you with both since WebForms and MVC differ quite a bit in the way they serve views. I’ll use MEF as the container but the code I make available for download at the end of article also provides examples in Unity. Other containers would be a variation of one of the two examples.

WPF

WPF continues to be Microsoft’s premier development platform for its XAML stack. The other two are Silverlight and Metro apps. With certain exceptions here and there, as well some framework differences, development on all three platforms is very similar. Views consist of XAML markup working in conjunction with code-behind pages. A popular pattern that is often associated almost synonymously with WPF (all XAML-stack platforms, in fact) is Model-View-ViewModel, or MVVM. I’ll demonstrate DI in a WPF application that implements the MVVM pattern.

A WPF application has one main view when the application starts up, which hosts two other views within it and offers a button to toggle between the two. The two views are CustomerListView and CustomerView, and the hosting view is MainWindowView. Each of the three views has a corresponding view-model class under the same name but with a view-model suffix instead of View.

A service class provides data models for both the CustomerListViewModel and CustomerViewModel classes. The class is called CustomerRepository and is responsible for obtaining information from a database. The CustomerRepository class implements an interface called ICustomerRepository and the view-models contain properties of the interface type, not the concrete class type.

As you may be able to tell, I’ve set the scene for class dependencies here. The MainWindowViewModel class has a dependency on the other two view-model classes; and each of those two have a dependency on an implementation of the ICustomerRepository interface. In order to satisfy all dependencies, all class instances need to be served up by a DI container. The first order of business is to set one up and register types and associations with it.

MEF uses discovery to find types and their associations to interfaces, so you have to decorate any class you want to export so that MEF will find it. I’ll leave out most of the class implementation code for brevity, but I’ll show the containment of the dependent types to explain afterward. Be sure to check the sidebar to see where you can download the entire solution of projects.

The MainWindowViewModel class contains the two other view-models and toggles between them using a command and property. The class is shown in Listing 9.

In this class, the dependencies are satisfied using property injection. As you can see, there are two properties of the types of the two other view-models and they are both decorated with the Import attribute. Later when this class is resolved, instances of those two view-models will be injected into these two properties. As you can probably guess, both of those view-models will also be exported so that MEF discovers and registers them. Because this class will be resolved and dependencies injected into them using properties, the class will need to be instantiated before its dependencies are injected, unlike a constructor injection technique.

To properly initialize and use this view-model, I need to set the CurrentViewModel property to the value _CustomerListViewModel property. The problem is that I can’t do this in the constructor because upon construction, the dependencies have not yet been injected. For this kind of situation, MEF gives us the IPartImportsSatisfiedNotification interface. When MEF resolves this view-model class, it checks for this interface and if it finds it implemented, it executes the OnImportsSatisfied method after it finishes injecting dependencies.

The other two view-model classes will also be exported and contain the repository as a dependency. For variation of technique demonstration, I’ve chosen to use constructor injection in these two cases.

[Export]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class CustomerListViewModel
   : view-modelBase
{
    [ImportingConstructor]
    public CustomerListViewModel(
       ICustomerRepository customerRepository)
    {
        _CustomersModel =
           customerRepository.GetAll();
    }
}

And

[Export]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class CustomerViewModel : view-modelBase
{
    [ImportingConstructor]
    public CustomerViewModel(
       ICustomerRepository customerRepository)
    {
        _CustomerModel =
           customerRepository.GetById(1);
    }
}

Marking the constructors with the ImportingConstructor attribute provides the constructor injection I’m looking for. The last thing I need is to export the CustomerRepository class and to associate it to the ICustomerRepository interface.

[Export(typeof(ICustomerRepository))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class CustomerRespository
   : ICustomerRepository
{
    public Customer GetById(int id) . . .
    public List<Customer> GetAll() . . .
    public void Update(Customer customer) . . .
}

Remember, due to the recursive nature of the DI container type-resolving process, resolving the MainWindowViewModel class later will resolve its dependencies, the other view-models. Resolving those two classes will resolve their dependencies, the CustomerRepository class.

Now that the classes are set up properly, the WPF application needs to discover them so the container can be assembled. The easiest place to do this is in the code-behind of the App.xaml file by overriding the OnStartup method. This will ensure that it happens at application startup.

public partial class App : Application
{
   public static CompositionContainer Container;
    
   protected override void OnStartup( StartupEventArgs e)
   {
       AggregateCatalog catalog =
          new AggregateCatalog();
       catalog.Catalogs.Add(
          new AssemblyCatalog(
          Assembly.GetExecutingAssembly()));
       Container = new CompositionContainer(
          catalog);
    
       base.OnStartup(e);
   }
}

I’m also storing the instance of the container in a static property so it can be accessed from anywhere in the application if needed.

Because the MainWindowView window is set up to be the startup window, its code-behind class executes when the application starts up after the aforementioned OnStartup method executes. The view-model for this window needs to be set to the window’s DataContext property. The other views will have theirs set through data templates and a standard view-model-to-Content property technique, but since this is the first one, it needs to be done manually. Rather than manually instantiating an instance of the MainWindowViewModel class, I’m going to ask the container for it, and I’ll do it in the MainWindowView class’ constructor.

public MainWindow()
{
   InitializeComponent();
    
   MainWindowViewModel view-model =
      App.Container.
        GetExportedValue<MainWindowViewModel>();
   this.DataContext = view-model;
}

This sets the DI wheels into motion. Nowhere else in this project will you be instantiating any view-model manually, or any type in which view-models are dependent. The application is constructed the way modern WPF, Silverlight, and Metro applications are written: using containment, view-switching, and with view-models mimicking the containment relationship between views.

When you write unit tests to test the CustomerRepository, you use that actual class so that you can test the database functionality, but when you write unit tests to test the view-models, you don’t necessarily need to access the database. Because the view-models depend on a type that implements the ICustomerRepository, you can provide view-models with either a test implementation or even better I’d use a mocking framework.

MVC

ASP.NET MVC is a terrific framework that allows us to develop Web applications in keeping with good architectural and development principles, including separation of concerns, testability, and dependency injection.

Like the view-models in the previous example, the controller classes you’ll use in the MVC example will depend on the same ICustomerRepository dependency. The CustomerRepository class and the ICustomerRepository interface remain exactly the same as in the WPF example, so I won’t repeat it here. The HomeController class will have its dependency injected using constructor injection and can be seen in Listing 10.

Notice that this class is exported with an identifier string that is the same name as the controller class but without the word “Controller”. Also note that the class is associated with the IController interface. This is the case with all other controllers that I write, and because there will be many classes associated with the same interface; the string identifier becomes important when the controllers get resolved later.

When they architected ASP.NET MVC, they took the idea of decoupled types right into the design of the framework. When you write a controller class in ASP.NET MVC, a controller factory instantiates the class and executes the desired action. The controller factory can be unhooked and a replacement put in its place so you can intercept how controller classes are served up. Because this controller has dependencies that need to be injected into it, it needs to be instantiated through the container.

You have a few choices in the way you implement DI in the MVC application, and the first choice is where to setup the container. You can do it in the Global.asax.cs class but what you really need to do in this file is to hook up a replacement to the default controller factory. You need to write a class called MefControllerFactory and hook it up in the application startup event of the Global.asax.cs class.

protected void Application_Start()
{
   AreaRegistration.RegisterAllAreas();
    
   RegisterGlobalFilters(GlobalFilters.Filters);
   RegisterRoutes(RouteTable.Routes);
    
   ControllerBuilder.Current
      .SetControllerFactory(
      new MefControllerFactory());
}

The line I added to this already-existing event is the last one, where I set the controller factory to an instance of the replacement class. You will set up the container in the MefControllerFactory class. The controller factory is in Listing 11.

I could have written a controller factory entirely from scratch by implementing the IController interface, but it was much easier to inherit from the default one and override the CreateController method. The constructor contains the code that will discover all of my exported types and store the container in a class variable for later use. When a controller is requested during a browser query, this class will get hit for a controller and it will execute the CreateController method. The argument, controllerName, will receive the name of the controller as it appeared in the URL used to query the application, without the word “Controller” in it. This’s why I exported the HomeController and identified it with the name, Home. The CreateController method queries the controller for a specific type that implements the IController interface using the identifier name. When the controller class gets resolved, the ICustomerRepository dependency will be injected into the constructor argument since I decorated the constructor with ImportingConstructor. From here, it’s available to any action that needs to use it.

As in the WPF example, you can write unit tests to test the controller actions and use a mock object to satisfy the necessary dependencies.

I want to take advantage of an opportunity presented in this example to demonstrate a way you can extend MEF to provide something that was not built into it. The controller factory has another available method that can be overridden in order to obtain a controller class, called GetControllerInstance. This method does not receive a controller name in an argument but instead receives a Type. This type corresponds to the controller class that needs to be instantiated. This seems a whole lot easier because then I can simply export the controller, with no need to identify it with a name or associate it with the IController interface. The problem is that the MEF container does not come equipped with a method to resolve a type given an actual Type argument; so I’ll extend it by writing an extension method. You can see my extension method in Listing 12.

This extension method adds a method to the container called GetExportedValueByType. This method scans the registered types and looks for one that matches the Type argument sent into the method. Now you can resolve the controllers in the controller factory without the need for its name, and you can change the exportation of the controller classes to a simple [Export].

protected override IController
   GetControllerInstance(
      RequestContext requestContext,
      Type controllerType)
{
    return _Container.GetExportedValueByType(
       controllerType) as IController;
}

There’s a new feature added to MVC 3 called the dependency resolver which offers yet another way of resolving controllers. In fact, it allows you to resolve many other things in ASP.NET MVC. The full code for this article includes examples of its usage, but for the purposes of brevity I will not discuss it here.

WebForms

The last example of DI usage I will demonstrate involves a technology that many think cannot be subject to DI and called it one of its shortcomings: ASP.NET WebForms. Unlike ASP.NET MVC, the WebForms architecture is one of a much coupled nature. ASPX pages are combined with code-behind class and at runtime, the two are combined and a virtual page class is created and executed. This is where the page life-cycle comes from and why we get several great events into which we can inject code. Sadly this also means that the code-behind class cannot be instantiated and served by an outside influence, since it needs to remain under ASP.NET management the entire time. However, like ASP.NET MVC, there is a mechanism in place that builds the classes for us and it’s into that you can tap.

Pages in ASP.NET WebForms are served up using a class called PageHandlerFactory. This class is installed as an HTTP Handler Factory and is meant to return an instance of an HTTP Handler; in this case, a class that is derivative from System.Web.UI.Page. What you can do is override this process with your own handler factory that derives from the standard one. By overriding the method that returns the Page class, you can call upon the base so that you can obtain that page class without interfering with the process, then you can inject your dependencies.

Construction injection is out of the question here because you cannot resolve the page class using a container, so you have to resort to property injection. MEF lets you do this easily by declaring the dependency properties and decorating them with the Import attribute. The dependency class in this case remains the CustomerRepository class and its configuration for MEF compliance remains the same as in the two previous examples. The ASPX page’s code-behind class does not need to get decorated with anything at the class level, since it will not be served through the container, only at the property level for the dependencies it may contain.

public partial class Customers
 : System.Web.UI.Page
{
    [Import]
    ICustomerRepository _CustomerRepository;
 
    protected void Page_Load(object sender,
                             EventArgs e)
    {
        grdCustomers.DataSource =
           _CustomerRepository.GetAll();
        grdCustomers.DataBind();
    }
}

I’ll show you how to resolve that class’ dependencies in a few minutes, but first you have to configure the container in the WebForms application.

As in the MVC example, you can go to the Application_Start event in the Global.asax.cs file to set up the container.

protected void Application_Start(object sender,
                                 EventArgs e)
{
    AggregateCatalog catalog =
       new AggregateCatalog();
    catalog.Catalogs.Add(new AssemblyCatalog(
       Assembly.GetExecutingAssembly()));
    CompositionContainer container =
       new CompositionContainer(catalog);
 
    Application["Container"] = container;
}

Also like the previous example, you’ll use the Application store to hang on to the container. Next, you have to create a class that will replace the PageHandlerFactory class.

I’ve created a class called MefPageHandlerFactory, which will override the GetHandler method and obtain the Page class by calling on the base. Listing 13 shows the factory class.

After you’ve obtained the page class, you’ll use a feature that MEF provides. By calling the SatisfyImportsOnce method, you’re telling MEF to run the class sent into the argument through the resolve process and attempt to resolve any properties it finds decorated with the Import attribute. When the page is returned at the end of the method, it will be equipped with instances of the proper classes in its dependency properties.

The last thing you need to do is install the new handler factory in the web.config file by assigning it as the handler to be used for anything with an aspx extension.

<system.web>
  <httpHandlers>
    <add path="*.aspx" verb="*"
      type="DI.WebForms.MefPageHandlerFactory" />
  </httpHandlers>
</system.web>

Unfortunately, unit-testing WebForms code-behind pages is next to impossible as the class cannot be instantiated on its own. This remains one of WebForms’ shortcomings.

That being said, I think I need to say something in defense of WebForms. Business code should be written so it can be tested on its own, regardless of the client implementing it. ASP.NET MVC lets us unit test controller actions but that does not mean this should serve as the test for your business logic. Controller actions return a certain result based on input arguments and that’s what should be tested by unit tests, not that the customer was saved properly. If you design applications to accommodate this, the lack of ability to test a WebForms code-behind class will seem a little less significant and WebForms may be able to retain some of the glory it once carried as a first class development platform for Web applications. I say this as an active developer in both the WebForms and MVC platforms.

Conclusion

As you can see, dependency injection solves several problem areas in development. It allows you to decouple code components from one another and it lets you stop worrying about instantiating classes to send into other classes. Solving these two problems also sets up your software for easy testability later.

There are many elements of DI that I couldn’t cover in this article. Among them is the resolving multiple implementations of an interface as well as defining which of several registered implementations gets resolved, which is possible through configuration files. Most containers provide both of these features, each in its own variety.

I also couldn’t cover every container out there. Besides MEF, Unity, NInject, and Castle Windsor, there are also StructureMap and Spring.NET. I apologize to the developers of the latter two for not providing coverage within this article but I’ll go on record as saying that both StructureMap and Spring.NET are first-class citizens in the DI world and top-shelf products.

The examples in this article should give you a great head-start on using dependency injection. The three scenarios should also serve as a good kick-off point for just about any application you are writing. Whether you’re using a Microsoft container or a third-party one, using DI in your applications will ensure that you’re writing decoupled, manageable, and testable components, and also very importantly, it’s really, really cool.