MVC 3 Dependency Resolver or Ninject MVC plugin?

Question

In MVC 3 they added a Dependency Resolver what I been using. While answering someone question someone commented on you should use the Ninject MVC 3 plugin.

So my question is why use it over the built in one? If it is the way to go how do you setup it up?

Question

So above is the link to the question that I answered.

Answer 1

ASP.NET MVC 3 provides a dependency injection service which will hook into whatever dependency resolver you choose to implement. The Ninject MVC 3 plugin is very simple in its function because all it must do is implement the type-resolution methods defined in System.Web.Mvc.IDependencyResolver and call the appropriate Ninject methods to return a requested type.

Whether you choose to use your own IDependencyResolver and map it to Ninject (or any other dependency injection framework), or you choose to use the freely available Ninject MVC 3 plugin, is mostly a trivial distinction.

Here's a fully-functional example of what a hand-rolled, Ninject-compatible IDependencyResolver might look like. The Ninject MVC 3 plugin would be fundamentally very similar:

public class NinjectDependencyResolver : IDependencyResolver
{
    private readonly IKernel _kernel;

    public NinjectDependencyResolver(IKernel kernel) {
        _kernel = kernel;
    }

    public object GetService(Type serviceType) {
        return _kernel.TryGet(serviceType, new IParameter[0]);
    }

    public IEnumerable<object> GetServices(Type serviceType) {
        return _kernel.GetAll(serviceType, new IParameter[0]);
    }
}

The key point here is that ASP.NET MVC does not provide a full-fledged dependency injection framework; it provides only the layer needed to retrieve a required type instance by way of an IoC container (i.e. Ninject) at specific points throughout the ASP.NET MVC request pipeline (Controller resolution, View resolution, etc).

_{Note: if any of the terminology I used isn't quite accurate, please inform me.}

Answer 2

The Ninject.Web.MVC extension (or Ninject.MVC3 NuGet package) use a dependency resolver internally too. So basically it is using the same mechanism. But there are several reasons to use the extension rather than implementing an own dependency resolver:

1. Why implementing an own dependency resolver when there's already an extension doing exactly the same? Using the same implementation than others makes it much easier to support you when you have a problem. Furthermore the more using the same implementation the more stable it gets. (See point 4).
2. The extension is more than just a dependency resolver. See http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/ for a list of all features that come with the extension.
3. It adds support for fast deactivation of objects InRequestScope after the request ends by default. This prevents that applications with a heavy load run into an OutOfMemory exception.
4. The dependency resolver in your post and the one above both have a problem. In some situations under heavy load your application will crash and only display yellow pages of death until the application is restarted. I don't like to answers all the question that will come in future only because a faulty dependency resolver is used. Add at least a .ToList() to the GetServices
5. Support for InRequestScope will be removed in Ninject 2.4 to remove the dependency to System.Web to reduce the number of build targets. This is a breaking change. But projects based on one of the Web extensions will only need a very minimalistic change to get it running again. InRequestScope will still be available to projects using one of these extensions. Custom implementations will have to add support themselves.