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，就此而言）。虽然许多人混淆了服务位置和依赖注入，但它们是two extremely different attempts to solve some common problems related to programming to interfaces。

然而，当你权衡服务定位器与DI的优缺点时，你会发现服务定位器确实是一种反模式，因为它引入了比它解决的问题更多的问题。虽然它旨在解决一些问题，但它实际上并没有解决DI无法解决的任何问题。

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

1 个答案: