最近我读过马克·西曼的文章 http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/关于服务定位器反模式。

作者指出了 ServiceLocator 是反模式的两个主要原因：

1. API使用问题（我对此非常满意）
   当类使用服务定位器时，很难看到它的依赖关系，因为在大多数情况下，类只有一个无参数构造函数。 与 ServiceLocator 相比，DI 方法通过构造函数的参数显式公开依赖关系，因此可以在 IntelliSense 中轻松查看依赖关系。

2. 维修问题（这让我很困惑）
   考虑下面的例子

我们有一个班'MyType'它采用服务定位器方法：

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();
    }
}

现在我们要向“MyType”类添加另一个依赖项

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();
            
        // new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}

这就是我的误解开始的地方。作者说：

判断您是否正在引入重大变更变得更加困难。您需要了解使用服务定位器的整个应用程序，编译器不会为您提供帮助。

但是等一下，如果我们使用 DI 方法，我们将在构造函数中引入与另一个参数的依赖关系（在构造函数注入的情况下）。问题仍然存在。如果我们可能忘记设置 ServiceLocator，那么我们可能会忘记在 IoC 容器中添加新映射，并且 DI 方法也会出现相同的运行时问题。

另外，作者提到了单元测试的困难。但是，DI 方法不会有问题吗？我们不需要更新实例化该类的所有测试吗？我们将更新它们以传递新的模拟依赖项，以使我们的测试可编译。而且我认为更新和花费时间没有任何好处。

我并不是想捍卫服务定位器方法。但这种误解让我觉得我失去了一些非常重要的东西。有人能打消我的疑虑吗？

更新（摘要）：

我的问题“服务定位器是反模式吗”的答案实际上取决于具体情况。我绝对不会建议将其从您的工具列表中删除。当您开始处理遗留代码时，它可能会变得非常方便。如果您足够幸运，处于项目的最开始阶段，那么 DI 方法可能是更好的选择，因为它比服务定位器具有一些优势。

以下是一些主要差异，这些差异说服了我不在我的新项目中使用服务定位器：

• 最明显和最重要的是：服务定位器隐藏了类依赖性
• 如果您正在使用某些 IoC 容器，它可能会在启动时扫描所有构造函数以验证所有依赖项，并为您提供有关缺少映射（或错误配置）的立即反馈；如果您使用 IoC 容器作为服务定位器，则这是不可能的

有关详细信息，请阅读下面给出的精彩答案。

如果您将模式定义为反模式只是因为在某些情况下它不适合，那么它就是反模式。但按照这个推理，所有模式也将是反模式。

相反，我们必须查看模式是否有效，对于服务定位器来说，有几个用例。但让我们首先看一下您给出的示例。

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();

        // new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}

该类的维护噩梦是依赖关系被隐藏。如果您创建并使用该类：

var myType = new MyType();
myType.MyMethod();

如果使用服务位置隐藏它们，您不明白它具有依赖关系。现在，如果我们改用依赖注入：

public class MyType
{
    public MyType(IDep1 dep1, IDep2 dep2)
    {
    }

    public void MyMethod()
    {
        dep1.DoSomething();

        // new dependency
        dep2.DoSomething();
    }
}

您可以直接发现依赖关系，并且在满足它们之前不能使用这些类。

在典型的业务应用程序中，您应该避免使用服务位置。它应该是没有其他选择时使用的模式。

该模式是反模式吗？

No.

例如，如果没有服务位置，控制容器的反转将无法工作。这就是他们在内部解决服务的方式。

但更好的例子是 ASP.NET MVC 和 WebApi。您认为是什么使得控制器中的依赖注入成为可能？没错——服务地点。

你的问题

但是等一下，如果我们使用 DI 方法，我们会引入一个 与构造函数中另一个参数的依赖关系（如果是 构造函数注入）。问题仍然存在。

还有两个更严重的问题：

1. 通过服务定位，您还可以添加另一个依赖项：服务定位器。
2. 您如何判断依赖项应具有哪个生命周期，以及应如何/何时清理它们？

通过使用容器的构造函数注入，您可以免费获得它。

如果我们可以 忘记设置 ServiceLocator，那么我们可能会忘记添加新的 我们的 IoC 容器和 DI 方法中的映射将具有相同的 运行时问题。

这是真的。但通过构造函数注入，您不必扫描整个类来找出缺少哪些依赖项。

一些更好的容器还会在启动时验证所有依赖项（通过扫描所有构造函数）。因此，使用这些容器，您会直接收到运行时错误，而不是在稍后的某个时间点。

另外，作者提到了单元测试的困难。但是，DI 方法不会有问题吗？

不会。因为您不依赖于静态服务定位器。您是否尝试过使用静态依赖项进行并行测试？这并不好玩。