ServiceLocator是反模式吗？

Question

最近我读了Mark Seemann关于Service Locator反模式的文章。

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

>

API使用问题（我对此很满意）
当类使用服务定位器时，很难看到它的依赖关系，因为在大多数情况下，类只有一个PARAMETERLESS构造函数。与ServiceLocator不同，DI方法通过构造函数的参数显式地公开依赖项，所以在IntelliSense中很容易看到依赖项。

维护问题（这让我感到困惑）
请考虑以下示例

我们有一个“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方法可能是一个更好的选择，因为它比服务定位器有一些优势。

以下是说服我在新项目中不使用Service Locator的主要差异：

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

详情请阅读以下精彩回答。

Answer 1

从测试的角度来看，服务定位器是不好的。参见Misko Hevery的Google Tech Talk nice解释，代码示例http://youtu.be/RlfLCWKxHJ0从8:45开始。我喜欢他的比喻:如果你需要25美元，直接要钱，而不是掏出钱包。他还将服务定位器比作一个干草堆，里面有你需要的针，并且知道如何找回它。因此，使用服务定位器的类很难重用。

Answer 2

我还想指出，如果您重构遗留代码，Service Locator模式不仅是一种反模式，而且是一种实际需要。没有人会在数以百万计的代码行上挥舞魔杖，突然间所有的代码都准备好了DI。因此，如果您想开始将DI引入现有的代码库，通常情况下，您会慢慢改变事情，使其成为DI服务，而引用这些服务的代码通常不是DI服务。因此，这些服务将需要使用ServiceLocator来获取那些已转换为使用DI的服务的实例。

因此，当重构大型遗留应用程序以开始使用DI概念时，我想说服务定位器不仅不是反模式，而且它是将DI概念逐步应用于代码库的唯一方法。

Answer 3

如果您仅仅因为某些情况下模式不适合而将模式定义为反模式，那么是的，这是一个反模式。但根据这种推理，所有模式都将是反模式的。

相反，我们必须查看模式是否有有效的用法，对于服务定位器，有几个用例。但是让我们从您给出的示例开始。

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();
    }
}

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

在典型的业务线应用程序中，出于这个原因，您应该避免使用服务位置。当没有其他选项时，应该使用这种模式。

没有。

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

但是一个更好的例子是ASP.NETMVC和WebApi。你认为是什么使得控制器中的依赖注入成为可能？没错——服务位置。

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

还有两个更严重的问题：

< li >对于服务定位，您还添加了另一个依赖项:服务定位器。 < li >如何判断依赖项应该具有哪个生存期，以及应该如何/何时清理它们？

使用容器的构造函数注入可以免费获得。

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

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

一些更好的容器也会在启动时验证所有依赖项（通过扫描所有构造函数）。因此，对于这些容器，您可以直接获得运行时错误，而不是在以后的某个时间点。

此外，作者还提到了单元测试的困难。但是，我们对DI方法不是有问题吗？

不，因为您不依赖静态服务定位器。你尝试过让并行测试使用静态依赖吗？一点都不好玩。