为什么MVC4使用服务定位器反模式？

Question

在阅读Mark Seemann的"Dependency Injection in .NET"后，我远离Service Locator，这是一种反模式。

阅读the release notes on MVC 4后，我看到了：

  

通过DependencyResolver改进控制反转（IoC）：Web API   现在使用由MVC的依赖项实现的服务定位器模式   解析器以获取许多不同设施的实例。

因此，我对于微软在2012年使用服务定位器的原因感到好奇和困惑。

Answer 1

这是一个你不应该关心的实现细节。重要的是，现在Web API使用DependencyResolver来解决许多不同设施的依赖关系，只要您想插入这些设施，就可以使用真正的依赖注入。因此，在您的代码中，您将使用真正的依赖注入。如果Microsoft没有使用DependencyResolver，那么您必须在代码中使用它（作为服务定位器反模式），以便在您想要实现某些自定义功能时解决依赖关系。这对你来说不好。现在它对微软来说是不好的，但你并不关心它们。

  

因此，我对于微软在2012年使用服务定位器的原因感到好奇和困惑。

因为设计框架与使用框架设计应用程序不同。在设计可重用的框架（如ASP.NET MVC）时，需要考虑一些不同的事情，而不仅仅是书中所写的内容。一些例子是以这样一种方式设计框架，使用这个框架的人将能够利用这个框架在他的代码中使用书中编写的最佳实践。

Answer 2

正如Darin所指出的，ASP.NET MVC 4是一个框架，并且与容器无关。这就是为什么它以IDependencyResolver的形式提供服务定位器的原因。这允许任何人插入他们选择的容器。

但是，我不会称之为反模式。这允许您使用您选择的容器，但它不会强迫您应用程序开发人员使用服务位置。如果框架迫使开发人员使用服务位置，那么我会称之为反模式。但构建ASP.NET MVC应用程序的开发人员可以通过构造函数注入，属性设置或服务位置自由使用DI。这是他们的选择。

查看由我或ASP.NET MVC团队发布的依赖注入的所有ASP.NET MVC示例。在几乎所有情况下，他们都在使用构造函数注入。他们没有使用服务地点。

实际上，大多数ASP.NET MVC源代码本身并不使用服务位置来检索依赖项。 MVC调用遗留API等服务定位器的几个关键位置。但就是这样。