在阅读了Mark Seemann的"Dependency Injection in .NET"之后，我远离Service Locator，这是一种反模式 .
在阅读the release notes on MVC 4时，我看到：
通过DependencyResolver改进了控制反转（IoC）：Web API现在使用MVC依赖解析器实现的服务定位器模式来获取许多不同设施的实例 .
因此，我对于微软在2012年使用服务定位器的原因感到好奇和困惑 .
在阅读了Mark Seemann的"Dependency Injection in .NET"之后，我远离Service Locator，这是一种反模式 .
在阅读the release notes on MVC 4时，我看到：
通过DependencyResolver改进了控制反转（IoC）：Web API现在使用MVC依赖解析器实现的服务定位器模式来获取许多不同设施的实例 .
因此，我对于微软在2012年使用服务定位器的原因感到好奇和困惑 .
2 回答
那个's an implementation detail that you shouldn't关心 . 重要的是，现在Web API使用DependencyResolver来解决许多不同设施的依赖关系，只要您想插入这些设施，就可以使用真正的依赖注入 . 因此，在您的代码中，您将使用真正的依赖注入 . 如果Microsoft没有使用
DependencyResolver，那么您的代码必须使用它（作为服务定位器反模式），以便在您想要实现某些自定义功能时解决依赖关系 . 这对你不利 . 现在它对微软不利，但你不关心它们 .因为设计框架与使用框架设计应用程序不同 . 在设计可重用的框架（如ASP.NET MVC）时，需要考虑一些不同的事情，而不仅仅是书中所写的内容 . 一些示例是以这样的方式设计框架：使用此框架的人将能够利用该框架在其代码中的书中编写的最佳实践 .
正如Darin指出的那样，ASP.NET MVC 4是一个框架，并且与容器无关 . 这就是为什么它以
IDependencyResolver的形式提供服务定位器 . 这允许任何人插入他们选择的容器 .但是，我不会强迫 you 应用程序开发人员使用服务位置 . 如果框架迫使开发人员使用服务位置，那么我会称之为反模式 . 但构建ASP.NET MVC应用程序的开发人员可以通过构造函数注入，属性设置或服务位置自由使用DI . 这是他们的选择 .
查看由我或ASP.NET MVC团队发布的所有ASP.NET MVC依赖注入示例 . 在几乎所有情况下，他们都在使用构造函数注入 . 他们没有使用服务地点 .
实际上，大多数ASP.NET MVC源代码本身并不使用服务位置来检索依赖项 . MVC调用遗留API等服务定位器的几个关键位置 . 但那是关于它的 .