Dependency Injection in MVC 3–with Views | John V. Petersen


: 2


If you have not read the first post in this series, please do so as these samples build on that post.

At first, it may appear that MVC 3’s Dependency Injection is not all that different than what we had in MVC 1 and 2. The fact is, MVC 3 gives us a lot more flexibility, and for sure, Dependency Injection is a first class citizen in the ASP MVC Framework. Using the Unity IoC Container, let’s take a look at how views can take advantage of Dependency Injection.

View Page Class

  1. public class ViewPageClass : WebViewPage
  2. {
  3.     [Dependency]
  4.     public SomeService SomeService { get; set; }
  6.     public override void Execute()
  7.     {
  9.     }
  10. }

Our View Page Class is very simple. It inherits from WebViewPage and has a public property to hold the SomeService reference. Notice that we are using the Unity Dependency attribute to indicate that this property is to be hydrated via Dependency Injection. Behind the scenes, DepedencyResolver is going to take care of this for us – as long as we have an entry for SomeService! Let’s take a look at our Razor View Page:

Razor View

  1. @inherits mvc3app.ViewPageClass
  4. <h1>This is View With Some SomeService!</h1>
  7. <h2>@SomeService.ToString()</h2>

Because our view inherits from the ViewPageClass, it gets access to the SomeService Property. And from there, the view has access to all of SomeService’s public attributes and methods.

The IoC Container already contains a registration entry for SomeService. While we can add an entry to resolve ViewPageClass, we are not required to do so. If an entry does not exist in the current IoC Container, MVC will then check to see if class definition exists. If so, MVC will use that definition.

Here is our modified Home Controller method:

Home Controller Index Action

  1. public ActionResult Index()
  2. {
  3.     return View(“ViewWithSomeService”);
  4. }

Again, using the UnityContainerSetup and running the application, here is what we now see for our default view:


Where Dependency Injection in MVC 1 and 2 dealt with controller (via the controller factory) – the MVC 3 implementation is much more comprehensive. Whether you are dealing with controllers, views, model binders or any other class, the DepedencyResolver will be used to fetch the correct instance. Ultimately, what DependencyResolver fetches is determined by your specific IoC Container. This is an important point to stress – DependecyResolver is just a façade over the specific IoC Container you choose to use – an architecturally, this yields a better design because our code does not need to know the specifics of any particular IoC container. For example, I don’t need to know about StructureMap’s GetInstance Method or Unity’s Resolve methods – nor does my application need to know the specifics of any other container because it’s point of contact is DependencyResolver. Regardless of which container I use, if I want to get a specific instance: