在阅读了 Mark Seemann的“.NET 中的依赖注入”之后，我远离了反模式的服务定位器。
在阅读MVC 4 上的发行说明后，我看到：
通过 DependencyResolver 改进控制反转 (IoC)：Web API 现在使用 MVC 的依赖解析器实现的服务定位器模式来获取许多不同设施的实例。
因此，我对微软为什么会在 2012 年使用服务定位器感到好奇和困惑。
问问题
10166 次
2 回答
51
这是您不应该关心的实现细节。重要的是，现在 Web API 使用 DependencyResolver 来解决许多不同设施的依赖关系，您将能够在想要插入这些设施时使用真正的依赖注入。因此，在您的代码中，您将使用真正的依赖注入。如果 Microsoft 没有使用，DependencyResolver那么当您想要实现某些自定义功能时，您必须在代码中使用它（作为服务定位器反模式）以解决依赖关系。这对你不利。现在这对微软不利，但你不关心它们。
因此，我对微软为什么会在 2012 年使用服务定位器感到好奇和困惑。
因为设计框架与使用框架设计应用程序不同。在设计诸如 ASP.NET MVC 之类的可重用框架时，需要考虑一些不同的事情，而不仅仅是书中所写的内容。一些示例是以这样一种方式设计框架，即使用此框架的人将能够在使用此框架的代码中利用书中编写的最佳实践。
于 2012-02-23T07:59:56.030 回答
35
正如 Darin 所指出的，ASP.NET MVC 4 是一个框架，并且与容器无关。这就是为什么它以IDependencyResolver. 这允许任何人插入他们选择的容器。
但是，我不会将其称为反模式。这允许您使用您选择的容器，但不会强制应用程序开发人员使用服务位置。如果框架强制开发人员使用服务位置，那么我将其称为反模式。但是构建 ASP.NET MVC 应用程序的开发人员可以通过构造函数注入、属性设置或服务定位自由地使用 DI。这是他们的选择。
查看我或 ASP.NET MVC 团队发布的所有 ASP.NET MVC 依赖注入示例。在几乎所有情况下，他们都在使用构造函数注入。他们没有使用服务位置。
事实上，大多数 ASP.NET MVC 源代码本身并不使用服务位置来检索依赖项。MVC 在一些关键位置调用旧 API 等的服务定位器。但仅此而已。
于 2012-03-12T16:09:07.613 回答