As you may or may not know, Dependency Injection is an implementaion of the Inversion of Control (IoC) design principle, a principle that promotes the loose coupling of objects. This helps with both code maintenance, in that changes to one class/layer won’t effect others around it, and unit testing. One place where this comes in really handy in an MVC application is in the interation between Controllers and Models (be they domain classes, repositories or Units of Work). Dependency injection is made up of two key components, a constructor injector and an IoC Container.
Traditionally, controllers contain parameterless default constructors. It is common to see repository objects created inside this constructor or inside action methods. This creates a tight coupling between the controller class and the repo class.
However, what if we were to have the IoC container handle the creation of repository objects instead. The controller no longer has a tight coupling to the repo. So how can we do this. Essentailly, we use a constructor injector. Basically this is a constructor, that we add to our controller, that takes in an abstraction of the repo class as a parameter, in other words a Repository Interface class. The IoC container then injects the concrete implementation of the interface into the controller at runtime, when that constructor is invoked.
So how does the IoC container do this, and what actually is it!?
IoC Containers
IoC containers are essentially third-party dll’s that you include in your project to carry out the heavy lifting of injecting and managing your dependent objects. One of the most popular (and the one we went with) is Ninject. You can download the latest build through Nuget. We added it to our MVC web project, created a folder called Infrastructure and added our class to manage our injections. Without going into too much detail your new class inherits from the IDependencyResolver Interface. In this we implement the AddBindings method, and it is in here that the magic happens as it were. In here we list our dependencies, e.g.
kernel.Bind<IMembershipAccessor>().To<MembershipAccessor>();
What we are looking at here is our Repo/UnitOfWork or in our case a UnitOfWork wrapper class (See previous post for more details on this) which we are binding to an Interface that it inherits from. What this means is that if we specify in our controller’s constructor that we want to use the IMembershipAccessor class, this IoC container will instantiate it as an object of type MembershipAccessor. This is pretty cool if I do say so myself. Here’s what our constructor inside our controller would look like:
private IMembershipAccessor _membershipAccessor;
public MembersController(IMembershipAccessor membershipAccessor)
{
_membershipAccessor = membershipAccessor;
}
As you can see the controller doesnt contain a single reference to a concrete class, only an Interface, yet when that constructor is executed, an instance of the MembershipAccessor class is created. Not only does this mean coupling has been improved but as you can imagine this opens up huge opportunities for us in terms of unit testing. Our next post will detail how we set up our testing environment and we will make further reference to how this Dependency Injection setup has aided better Unit Testing for us.
Oh one other thing, make sure you add this line of code to your global.asax app_start method (if your using Ninject anyways)
DependencyResolver.SetResolver(new NinjectDependencyResolver());
where NinjectDependencyResolver is the name of our class that inherits from IDependencyResolver.