我们可以在MVC中通过实现IDependencyResolver或扩展DefaultControllerFactory来实现DI
我过去认为这两种不同的方法没有太大的区别。
然而,我正在完成我的MVC书,它让我实现我自己的ControllerFactory(而不是扩展默认值),并在CreateController方法,它实际上有:
(IController) DependencyResolver.Current.GetService(targetType);
看起来DefaultControllerFactory实际上使用了DependencyResolver
这两者之间一定有区别,我想这让我很困惑。
1)这本书是否让我使用依赖解析器来简化他们对CustomControllerFactory的实现,而实际的DefaultControllerFactory不使用它?
2)我很难理解这两者的目的。我曾经认为这只是实现DI的两种不同方式,但我越深入研究,就越觉得它们完全不同。看起来依赖解析器是所有控制器实例化的地方
3)是否存在在两者之间进行选择的最佳实践?也许有一些利弊?
EDIT:为了清晰起见,我决定上传整个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);
}
坚持使用DefaultControllerFactory
IDependencyResolver是服务定位器反模式的一个例子,在我看来,它不应该被添加到MVC(或Web API)中。尽管许多人混淆了服务位置和依赖注入,但它们是解决与接口编程相关的一些常见问题的两种截然不同的尝试。
然而,当您权衡Service Locator与DI的优缺点时,您会发现Service Locator确实是一个反模式,因为它引入的问题远远多于它解决的问题。尽管它声称可以解决一些问题,但实际上它并不能解决任何DI不能更好地解决的问题。