为什么MVC4使用服务定位器反模式？
在阅读Mark Seemann的“Dependency Injection in .NET”之后 ，我远离了服务定位器 ，这是一种反模式。
在阅读MVC 4上的发行说明之后，我看到：
通过DependencyResolver改进控制反转（IoC）：Web API现在使用由MVC的依赖parsing器实现的服务定位器模式来获取许多不同工具的实例。
因此，我留下了好奇和困惑，为什么微软会在2012年使用服务定位器。
这是一个你不应该关心的实现细节。 重要的是，现在Web API使用DependencyResolver来parsing许多不同工具的依赖关系，只要想要插入这些工具，就可以使用真正的依赖关系注入。 所以在你的代码中你将会使用一个真正的dependency injection。 如果微软没有使用DependencyResolver那么你就必须在代码中使用它（作为服务定位器反模式），以便在你想要实现某些定制function时解决依赖性问题。 这会对你不好 。 现在这对微软来说不好，但是你不关心它们。
因此，我留下了好奇和困惑，为什么微软会在2012年使用服务定位器。
因为devise框架与使用框架devise应用程序不一样。 在devise诸如ASP.NET MVC之类的可重用框架时，有一些不同的事情需要考虑，而不仅仅是书中的内容。 举例来说，devise框架的方式是使用这个框架的人将能够利用这个框架的代码中的书中的最佳实践。
正如Darin所指出的那样，ASP.NET MVC 4是一个框架，并且是容器不可知的。 这就是为什么它以IDependencyResolver的forms提供服务定位器。 这允许任何人插入他们的select容器。
不过，我不会把这称为反模式。 这使您可以使用您select的容器，但不会强制应用程序开发人员使用服务位置。 如果框架迫使开发人员使用服务位置，那么我会称之为反模式。 但是构buildASP.NET MVC应用程序的开发人员可以通过构造函数注入，属性设置或服务位置自由使用DI。 这是他们的select。
查看我或ASP.NET MVC团队发布的所有dependency injection的ASP.NET MVC示例。 在几乎所有的情况下，他们正在使用构造函数注入。 他们没有使用服务地点。
实际上，大多数ASP.NET MVC源代码本身并不使用服务位置来检索依赖关系。 有几个关键的地方MVC调用传统的API等服务定位器。 但是这是关于它的。
