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.

Boarhound

Answer 1

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.

Molloy

@Remo Gloor - Whats the difference between Web.MVc extension and Ninject.MVC3? – Boarhound

It's the same. We keeped the name of the NuGet package Ninject.MVC3 as it existed before. – Molloy

@ Remo Gloor - So it is the same thing then? – Boarhound

@ Remo Gloor - How much of my code that I already have needs to be changed? – Boarhound

None. Just remove the App_Start part added by the nuget package See github.com/ninject/ninject.web.mvc/wiki/… – Molloy

@Remo Gloor - I am looking at it and it creates a bootstrapper(according to the github link). I never needed that in mine and I am not too found of it so do I really need it? – Boarhound

Repeating: Just delete the App_Start folder. – Molloy

@Remo Gloor - Ok switched over. Is there a difference between what I had and what was in the app_start? – Boarhound

Sry seems I missed that comment: There is no difference. That are just two ways of starting an MVC application using the extension. – Molloy

@Remo Gloor - why it is it being removed? I don't think I am using it but I will have to check. I always forget what most of the scope ones do. – Boarhound

Updated point 5: We want reduce the number of build targets. InRequestScope simply doesn't belong to Ninject core as it is not only for web projects. – Molloy

@ Remo Gloor - Ah I do use it. So can you point me to what I will need to keep it going once it changes? Also do you have a list of the scopes that will be available in 2.4 and what each one does. – Boarhound

@chobo2: Be a little patience. We will update the docu and write blog posts before the release explaining everything. – Molloy

@Remo Gloor - Ok can you edit this post once they become available? – Boarhound

I started a new project and I am using Ninject MVC 3. I see no InRequestScope. What do I use? Or where do I get InRequestScope? – Boarhound

Answer 2

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.}

Studer

That looks pretty much what I have now(see the other post). I heard(or I think I heard) that doing it yourself like this without the mvc plugin won't kill sessions when using nhibernate. – Boarhound

@Boarhound I haven't really got any experience with nHibernate or the problem you're describing, so I can't speak to it specifically. :[ – Studer

@chobo2, perhaps what you're referring to is Ninject's OnePerRequestModule this will wipe out anything bound InRequestScope as soon as the Request is over. It will also execute before any other EndRequest handlers are run. Unfortunately doing this yourself will not prevent this from happening. – Demibastion