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

Question

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

我曾经认为这两种不同的做法没有太大区别。

但是，我正在完成我的 MVC 书，它让我实现了自己的 ControllerFactory（而不是扩展默认值），并且在 CreateController 方法中，它实际上具有：

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

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

两者之间一定有区别，我认为这只是让我感到困惑。

问题

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

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

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 无法更好地解决的问题。