14

在 MVC 3 中，他们添加了我一直在使用的 Dependency Resolver。在回答某人对您发表评论的问题时，您应该使用 Ninject MVC 3 插件。

所以我的问题是为什么要使用它而不是内置的？如果这是要走的路，你如何设置它？

问题

以上是我回答的问题的链接。

4

2 回答 2

15

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）检索所需类型实例所需的层。

注意：如果我使用的任何术语不太准确，请告知我。

于 2011-03-01T20:51:31.910 回答
13

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 仍可用于使用这些扩展之一的项目。自定义实现必须自己添加支持。
于 2011-03-02T00:14:57.627 回答