c# - 通过扩展 DefaultControllerFactory 实现 DI 与实现 IDependencyResolver 之间的区别

Question

我们可以通过实现 IDependencyResolver 或扩展 DefaultControllerFactory 在 MVC 中进行 DI

我之前一直认为这两种不同的方式做起来没有太大的区别。

然而，我正在完成我的 MVC 书，它让我实现了我自己的 ControllerFactory(而不是扩展默认值)，并且在 CreateController 方法中，它实际上有:

(IController) DependencyResolver.Current.GetService(targetType);

所以看起来 DefaultControllerFactory 实际上使用了 DependencyResolver

两者之间肯定有区别，我认为这让我很困惑。

问题

1) 这本书是否让我使用依赖解析器来简化他们对 CustomControllerFactory 的实现，而实际的 DefaultControllerFactory 不使用它？

2) 我很难理解这两个的目的。我曾经认为这只是实现 DI 的两种不同方式，但我越深入，我越觉得它们是完全不同的。看起来依赖解析器是所有 Controller 被实例化的地方

3) 是否有尝试在两者之间进行选择的最佳实践？也许有一些优点和缺点？

编辑:为清楚起见，我决定上传整个 CreateController 方法:

  public IController CreateController(RequestContext requestContext, string controllerName)
  {
     Type targetType = null;

     switch (controllerName)
     {
        case "Product":
           targetType = typeof (ProductController);
           break;
        case "Customer":
           targetType = typeof (CustomerController);
           break;
        default:
           requestContext.RouteData.Values["controller"] = "Product";
           targetType = typeof (ProductController);
           break;
     }

     return targetType == null ? null : (IController) DependencyResolver.Current.GetService(targetType);
  }

Answer 1

坚持使用 DefaultControllerFactory。

IDependencyResolver is an example of the Service Locator anti-pattern ，并且应该，IMO，从来没有被添加到 MVC(或 Web API，就此而言)。虽然很多人混淆了 Service Location 和 Dependency Injection，但它们是 two extremely different attempts to solve some common problems related to programming to interfaces .

但是，当您权衡 Service Locator 与 DI 的优缺点时，您会发现 Service Locator 确实是一种反模式，因为它引入的问题远多于它解决的问题。虽然它声称可以解决一些问题，但实际上并没有解决任何 DI 不能更好解决的问题。