A Brief overview of what dependency injection is
Dependency injection is a software design pattern that allows a choice of component to be made at run-time rather than compile time. This can be used, for example, as a simple way to load plugins dynamically or to choose mock objects in test environments vs. real objects in production environments.- Wikipedia
In laymen's terms , it’s a way to have your class dependencies such as constructor parameters automagically passed in. Here is a simple example.
var kernel = new StandardKernel(); //Bind an interface to an implementation kernel.Bind<IConfigurationProvider>().To<SubtleConfiguration>(); //Ask for the implementation for the interface var configurationProvider = kernel.Get<IConfigurationProvider>();
This example uses a library called Ninject which I am quite fond of. In most dependency injection frameworks, you setup the binding before hand and someone in your code you would ask it for an implementation of a specific type. i.e. asking the dependency injection framework for an implementation it would get you back the SublteConfiguration. If the SubtleConfiguration also had dependencies in it’s constructor, it would go and check it’s bindings to see if it can new up a SubtleConfiguration object.
In ASP.NET MVC, we can leverage this to inject repositories or services into our controllers so that we can get rid of the messy “new Service()” calls and have the dependencies of those objects also satisfied on creation of those objects.
Start off by creating a new ASP.NET MVC project and installing ninject through either the nuget package explorer or nuget package manager console.
Note that I am referencing the ninject.mvc3 package from nuget here as this includes the NinjectDependencyResolver in the Ninject.Web.Mvc namespace that we need.
Set the DependencyResolver in the Application_Start method.
var kernel = new Ninject.StandardKernel(); kernel.Load(Assembly.GetExecutingAssembly()); DependencyResolver.SetResolver(new Ninject.Web.Mvc.NinjectDependencyResolver(kernel));
We have now told ASP.NET MVC to use Ninject to resolve all dependencies and we can now go ahead and register our bindings with ninject. You will notice that we have asked Ninject to load all the modules in the current executing assembly. You can create a module anywhere which Ninject will pickup automatically as it scans the assembly which was passed into the Load method for types that derive from NinjectModule and call the abstract Load method on them.
public interface IService { }
public class Service :IService { }
public class ServicesModule : NinjectModule
{
public override void Load()
{
Kernel.Bind<IService>().To<Service>();
}
}
One way of injecting the dependencies is through the constructor. Ninject supports this way and in our controller we can now overload the constructor.
public class HomeController : Controller
{
private IService service;
public HomeController(IService service)
{
this.service = service;
}
public ActionResult Index()
{
return View();
}
}
When the HomeController is newed up by MVC, it will use Ninject, which will in turn attempt to resolve all the dependencies of the constructor that takes the most arguments, in our case the constructor that takes the IService interface.
You can read more about how Ninject works at http://www.ninject.org
Read More
