MVC 3 Dependency Resolver或Ninject MVC插件？

Question

在MVC 3中,他们添加了一个依赖解析器,我一直在使用它.在回答某人的问题时,有人评论过你应该使用Ninject MVC 3插件.

所以我的问题是为什么用它来构建一个？如果是这样的话你怎么设置它？

题

所以上面是我回答的问题的链接.

Answer 1

ASP.NET MVC 3提供了一个依赖注入服务,它将挂钩到您选择实现的任何依赖项解析器.Ninject MVC 3插件的功能非常简单,因为它必须做的只是实现System.Web.Mvc.IDependencyResolver中定义的类型解析方法,并调用相应的Ninject方法来返回请求的类型.

无论您选择使用自己的IDependencyResolver并将其映射到Ninject(或任何其他依赖注入框架),或者您选择使用免费提供的Ninject MVC 3插件,大多数都是微不足道的区别.

这是一个功能齐全的例子,说明手动滚动,与Ninject兼容的IDependencyResolver可能是什么样子.Ninject MVC 3插件基本上非常相似:

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]);
    }
}

这里的关键点是ASP.NET MVC不提供完整的依赖注入框架 ; 它仅提供在整个ASP.NET MVC请求管道(控制器分辨率,视图分辨率等)中的特定点通过IoC容器(即Ninject)检索所需类型实例所需的层.

_{注意:如果我使用的任何术语不太准确,请通知我.}

Answer 2

Ninject.Web.MVC扩展(或Ninject.MVC3 NuGet包)也在内部使用依赖解析器.所以基本上它使用相同的机制.但是有几个原因使用扩展而不是实现自己的依赖解析器:

1. 为什么在已经有完全相同的扩展时实现自己的依赖解析器？使用与其他实现相同的实现可以在遇到问题时更轻松地为您提供支持.此外,使用相同的实现越多,它就越稳定.(见第4点).
2. 扩展不仅仅是一个依赖解析器.请参阅http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/以获取扩展程序附带的所有功能的列表.
3. 默认情况下,它在请求结束后添加了对快速停用对象InRequestScope的支持.这可以防止负载较重的应用程序遇到OutOfMemory异常.
4. 你帖子中的依赖解析器和上面的依赖解析器都有问题.在重负载的某些情况下,您的应用程序将崩溃,并且只有在重新启动应用程序之前才会显示黄页死机.我不喜欢回答将来会出现的所有问题,因为使用了错误的依赖解析器.至少将一个.ToList()添加到GetServices
5. 将在Ninject 2.4中删除对InRequestScope的支持,以消除对System.Web的依赖,以减少构建目标的数量.这是一个突破性的变化.但是基于其中一个Web扩展的项目只需要进行非常简单的更改即可让它再次运行.使用这些扩展之一的项目仍然可以使用InRequestScope.自定义实现必须自己添加支持.