DevTrends

Integrating The Unity.Mvc3 1.1 NuGet Package From Scratch

A new version of Unity.Mvc3 has been published that targets the recently released Unity 2.1. It is available as a NuGet Package (Unity.Mvc3) downloadable from within Visual Studio. You can also download the dll and the source code from codeplex. This article explains the changes in this release and goes on to explain how to do dependency injection in an MVC application using Unity.Mvc3.

Changes from 1.0

Following the release of a new version of Unity (2.1), I have updated the project to use this newer version. I have also changed the RegisterControllers extension method to be on IUnityContainer rather than the concrete UnityContainer type, which was a mistake that crept into the original release. The other changes are in the NuGet package itself. I have now added a dependency on the Unity NuGet package rather than relying on the consumer to install it either via NuGet or as part of Enterprise Library. I had initially held off on adding this dependency assuming that many developers would already have Unity installed as part of Enterprise Library, but I have been persuaded that the benefits outweight the drawbacks. I have also added a simple bootstrapper class that creates the Unity container, registers the controllers and then creates and registers the DependencyResolver with MVC.

Getting started with Unity.Mvc3

These changes mean that you can now get up and running much more quickly than with the previous release. The rest of this article will show how to start from scratch, building an MVC3 application that uses the Unity.Mvc3 NuGet package to allow dependency injection in a series of simple scenarios.

First we create a new MVC3 application and select the Internet Application Template to add some simple controllers and views to the project.

The Visual Studio 2010 New Project Dialog

Figure 1: The Visual Studio 2010 New Project Dialog

The ASP.NET MVC3 Internet Application Template

Figure 2: The Visual Studio 2010 New ASP.NET MVC3 Internet Application Template

The next thing to do is add the NuGet Unity.Mvc3 package to the project. Right-click on references and select Manage NuGet packages. Once the dialog appears, enter Unity.Mvc3 into the search box in the top right corner. After a few seconds, the results will be displayed in the centre panel. Select the Unity.Mvc3 package and click Install.

Manage NuGet Packages Context Menu Item

Figure 3: Manage NuGet Packages Context Menu Item

Manage NuGet Packages Dialog

Figure 4: Manage NuGet Packages Dialog

The NuGet installer will add Unity and Unity.Mvc3 DLL's to the project references and also add a couple of files to the root of the application. Unity.Mvc3.README.txt has some basic advice regarding the setup of Unity.Mvc3 and can be deleted once you are familiar with the package. Bootstrapper.cs is the file containing the code to initialise the Unity container and DependencyResolver. When we come to add dependencies later in the article, we will need to register them in this class.

using System.Web.Mvc;
using Microsoft.Practices.Unity;
using Unity.Mvc3;

namespace MvcApplication1
{
  public static class Bootstrapper
  {
    public static void Initialise()
    {
      var container = BuildUnityContainer();

      DependencyResolver.SetResolver(new UnityDependencyResolver(container));
    }

    private static IUnityContainer BuildUnityContainer()
    {
      var container = new UnityContainer();

      // register all your components with the container here
      // e.g. container.RegisterType<ITestService, TestService>();

      container.RegisterControllers();

      return container;
    }
  }
}

To hook up the Bootstrapper, we just need to edit the Application_Start method of the Global.asax and add a call to the static Initialise method.

protected void Application_Start()
{
  AreaRegistration.RegisterAllAreas();

  RegisterGlobalFilters(GlobalFilters.Filters);
  RegisterRoutes(RouteTable.Routes);

  Bootstrapper.Initialise();
}

We could have used the WebActivator NuGet package to automatically call the Bootstrapper.Initialise method at application startup, but doing this makes the code a little less understandable. Most developers know about the global.asax and can more easily work out what is going when we add the call manually to Application_Start.

You can now run the application and whilst you will not notice any difference to the user interface, behind the scenes, the controllers are now being resolved via Unity. How very exciting :-)

Adding a dependency

So now that we have Unity hooked into the MVC pipeline, we can actually start injecting some components into our controller. We are going to inject a (very) simple message service. When injecting components, we normally work with abstractions rather than concrete types, so first we create an IMessageService interface and then implement the interface in the MessageService class.

namespace MvcApplication1
{
  public interface IMessageService
  {
    string GetMessage();
  }    

  public class MessageService : IMessageService
  {
    public string GetMessage()
    {
      return "Hello from the MessageService";
    }
  }
}

Now, let's change the HomeController so it uses this component. We will use constructor injection which is the preferred method of dependency injection, particularly if the component must always be supplied as opposed to an optional component which may be injected via a property. So, we add a new constructor that takes in an IMessageService. To visually see that the components gets injected properly, we will change the Index action to use the GetMessage method of the service and output the result to the View (via the ViewBag which I would normally avoid and use strongly typed view models instead but it is fine for this demonstration).

using System.Web.Mvc;

namespace MvcApplication1.Controllers
{
  public class HomeController : Controller
  {
    private readonly IMessageService _messageService;

    public HomeController(IMessageService messageService)
    {
      _messageService = messageService;
    }

    public ActionResult Index()
    {
      ViewBag.Message = _messageService.GetMessage();

      return View();
    }

    public ActionResult About()
    {
      return View();
    }
  }
}

The last thing we need to do is to let Unity know about the MessageService. This is done by registering the component in the BuildUnityContainer method of the Bootstrapper class. Notice that we are using the RegisterType overload that allows us to map the IMessageService interface to the concrete MessageService class.

private static IUnityContainer BuildUnityContainer()
{
  var container = new UnityContainer();

  container.RegisterType<IMessageService, MessageService>();

  container.RegisterControllers();

  return container;
}

If you build and run the application at this point, you will see something similar to Figure 5 below. The DependencyResolver is being asked by the MVC framework to return a HomeController. The resolver uses Unity to work out that the HomeController constructor requires an IMessageService dependency to be satisfied. Unity knows about this interface and instantiates the concrete MessageService type which is then injected into the controller and returned to the MVC framework. Then in the Index action method, the GetMessage method of the injected IMessageService is called and the result added to the ViewBag and rendered on the page. Congratulations, you are doing dependency injection in MVC3!

MVC View Displaying The Message Created By The The MessageService

Figure 5: MVC View Displaying The Message Created By The The MessageService

Adding a dependency for the dependency

Let's make it a little bit more complicated by assuming that the MessageService has a dependency itself so when we resolve the HomeController, we need to inject an IMessageService as before, but the MessageService constructor now takes in an IMessageGenerator. Again we create an interface and concrete type.

namespace MvcApplication1
{
  public interface IMessageGenerator
  {
    string GetMessage();
  }

  public class MessageGenerator : IMessageGenerator
  {
    public string GetMessage()
    {
      return "Hello from the MessageGenerator";
    }
  }
}

Now we need to change the MessageService so it takes in the IMessageGenerator as a constructor argument. We will also change the GetMessage method so it uses the IMessageGenerator and also appends some text itself so we can see that the output has come from the MessageGenerator via the MessageService.

public class MessageService : IMessageService
{
  private readonly IMessageGenerator _messageGenerator;

  public MessageService(IMessageGenerator messageGenerator)
  {
    _messageGenerator = messageGenerator;
  }

  public string GetMessage()
  {
    return string.Concat(_messageGenerator.GetMessage(), " via the MessageService");
  }
}

Once again, we need to register the new component with Unity in the Bootstrapper:

container
  .RegisterType<IMessageService, MessageService>()
  .RegisterType<IMessageGenerator, MessageGenerator>();

Run the application and this time, the message should have changed to what is shown in Figure 6. If you are not familiar with dependency graph resolution, then you might be pleasantly suprised by this functionality. This is one of the reasons why IoC containers can be so useful. It is common to have dependency graphs many levels deep and it is very useful to be able to resolve the whole graph automatically.

MVC View Displaying The Message Created By The The MessageService And MessageGenerator

Figure 6: MVC View Displaying The Message Created By The The MessageService And MessageGenerator

IDisposable dependencies

The final example that we are going to look at is the case where a dependency implements IDisposable. In the vast majority of cases, if you are dealing with a disposable component in the context of an MVC application, you want to create the component at the start of the request and dispose of it at the end of the request. The obvious and extremely common example is the ORM context or session that functions as your unit of work. Whether you use NHibernate, Entity Framework or LINQ to SQL, you must dispose of your context/session at the end of the request. The original article goes into more detail about how the Unity.Mvc3 DepenendencyResolver disposes of components, but as a consumer of the package, all you really need to know is how to instruct the resolver to treat a component as disposable.

For this example, we will assume that MessageGenerator implements IDisposable. We have nothing to actually dispose of so we will just output some text so we can see that the method is called.

using System;
using System.Diagnostics;

namespace MvcApplication1
{
  public interface IMessageGenerator
  {
    string GetMessage();
  }

  public class MessageGenerator : IMessageGenerator, IDisposable
  {
    public string GetMessage()
    {
      return "Hello from the MessageGenerator";
    }

    public void Dispose()
    {
      Debug.WriteLine("Message Generator is being disposed");
    }
  }
}

To indicate to the dependency resolver that you want to dispose of a component, all you need to do is register it using the HierarchicalLifetimeManager. Again, I wrote about this in the previous Unity.Mvc3 article and you can find out more by reading that.

container
  .RegisterType<IMessageService, MessageService>()
  .RegisterType<IMessageGenerator, MessageGenerator>(new HierarchicalLifetimeManager());

Run the application and check the output window and you can see that every request, Dispose is called on the MessageGenerator. Whilst it might not be the most exciting demonstation, it is vital that you dispose of components properly to avoid memory leaks and connection timeouts.

Output Window Showing Message When MessageGenerator Is Disposed

Figure 7: Output Window Showing Message When MessageGenerator Is Disposed

Conclusion

Unity.Mvc 1.1 now targets the recently released Unity 2.1. The NuGet has been modified to have a dependency on the Unity NuGet package meaning that if you install Unity.Mvc without having Unity, it will automatically be downloaded and added to your project. A Bootstrapper has also been added to the package to decrease the number of steps necessary to integrate Unity.Mvc into your solution. This article includes a comprehensive walkthrough for getting users up to speed and provides several examples for adding dependency injection to MVC in a correct manner.

Useful or Interesting?

If you liked the article, we would really appreciate it if you would share it with your Twitter followers.

Share on Twitter