依赖注入和服务定位器模式之间有什么区别？

Question

这两种模式看起来都像是控制反转原理的实现。也就是说，对象不应该知道如何构建其依赖关系。

依赖注入（DI）似乎使用构造函数或设置器来“注入”它的依赖项。

使用构造函数注入的示例：

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

服务定位器似乎使用“容器”，它连接其依赖项并为 foo 提供它的栏。

使用服务定位器的示例：

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo()
  {
    this.bar = Container.Get<IBar>();
  }

  //...
}

因为我们的依赖项本身就是对象，所以这些依赖项具有依赖项，这些依赖项具有更多的依赖项，依此类推。于是，控制反转容器（或DI容器）诞生了。例如：Castle Windsor、Ninject、Structure Map、Spring 等）

但是 IOC/DI 容器看起来完全就像一个服务定位器。称其为 DI 容器是一个坏名字吗？ IOC/DI 容器只是另一种类型的服务定位器吗？当我们有很多依赖项时，我们主要使用 DI 容器，这是否有细微差别？

Answer 1

差异可能看起来很小，但即使使用 ServiceLocator，该类仍然负责创建其依赖项。它只是使用服务定位器来完成此操作。通过 DI，类被赋予了它的依赖关系。它既不知道，也不关心它们来自哪里。这样做的一个重要结果是 DI 示例更容易进行单元测试——因为您可以向它传递其依赖对象的模拟实现。如果您愿意，您可以将两者结合起来 - 并注入服务定位器（或工厂）。

Answer 2

当您使用服务定位器时，每个类都将依赖于您的服务定位器。依赖注入则不是这种情况。依赖注入器通常只会在启动时被调用一次，以将依赖项注入到某个主类中。该主类所依赖的类将递归地注入其依赖项，直到获得完整的对象图。

一个很好的比较：http://martinfowler.com/articles/injection.html

如果您的依赖注入器看起来像一个服务定位器，其中类直接调用注入器，它可能不是依赖注入器，而是一个服务定位器。

Answer 3

服务定位器隐藏依赖关系 - 您无法通过查看对象来判断它是否命中数据库（例如，当它从定位器获取连接时）。通过依赖注入（至少是构造函数注入），依赖关系是显式的。

此外，服务定位器打破了封装，因为它们提供了对其他对象的依赖关系的全局访问点。使用服务定位器，与任何单例一样：

指定前置和后置变得困难
客户端对象的条件
接口，因为它的工作原理
实施可能会受到干扰
从外部。

通过依赖注入，一旦指定了对象的依赖关系，它们就受到对象本身的控制。

Answer 4

马丁·福勒指出：

使用服务定位器，应用程序类通过
向定位器发送消息。通过注入，没有明确的请求，
该服务出现在应用程序类中——因此反转
控制。

简而言之：服务定位器和依赖注入只是依赖倒置原则的实现。

重要的原则是“依赖于抽象，而不是依赖于具体”。这将使你的软件设计“松耦合”、“可扩展”、“灵活”。

您可以使用最适合您需求的一种。对于拥有庞大代码库的大型应用程序，您最好使用服务定位器，因为依赖注入需要对代码库进行更多更改。

您可以查看这篇文章： 依赖倒置：服务定位器或依赖注入

也是经典：Martin 的控制容器反转和依赖注入模式Fowler

设计可重用类作者：Ralph E. Johnson & Brian Foote

然而，让我大开眼界的是： ASP.NET MVC：解析还是注入？这就是问题所在……作者：Dino Esposito

Answer 5

使用构造函数 DI 的类向使用代码表明存在需要满足的依赖关系。如果类在内部使用 SL 来检索此类依赖项，则使用代码不会意识到这些依赖项。这可能表面上看起来更好，但实际上了解任何显式依赖关系是有帮助的。从架构角度来看更好。在进行测试时，您必须知道某个类是否需要某些依赖项，并配置 SL 以提供这些依赖项的适当假版本。使用 DI，只需传递假货即可。虽然差别不大，但确实存在。

不过，DI 和 SL 可以一起工作。为常见依赖项（例如设置、记录器等）提供一个中心位置非常有用。给定一个使用此类 deps 的类，您可以创建一个接收 deps 的“真实”构造函数，以及一个从 SL 检索并转发到“真实”构造函数的默认（无参数）构造函数。

编辑：当然，当您使用 SL 时，您正在向该组件引入一些耦合。这很讽刺，因为这种功能的想法是鼓励抽象并减少耦合。这些担忧是可以平衡的，这取决于您需要在多少地方使用 SL。如果按照上面的建议完成，则只需在默认类构造函数中即可。

Answer 6

两者都是IoC的实现技术。还有其他实现控制反转的模式：

• 工厂模式
• 服务定位器
• DI (IoC) 容器
• 依赖注入
  （构造函数注入、参数注入（如果不需要）、接口注入的setter注入）
  ...

服务定位器和DI容器看起来更相似，它们都使用容器来定义依赖关系，将抽象映射到具体实现。

主要区别在于依赖关系的定位方式，在服务定位器中，客户端代码请求依赖关系，在 DI 容器中，我们使用容器来创建所有对象，并将依赖关系作为构造函数参数（或属性）注入。

Answer 7

添加的一个原因是受到我们上周为 MEF 项目编写的文档更新的启发（我帮助构建 MEF）。

一旦应用程序由潜在的数千个组件组成，就很难确定是否可以正确实例化任何特定组件。我所说的“正确实例化”是指，在这个基于 Foo 组件的示例中，IBar 的实例将可用，并且提供它的组件将

• ：其所需的依赖关系，
• 不涉及任何无效的依赖关系循环，并且
• 在 MEF 的情况下，仅提供一个实例。

在您给出的第二个示例中，构造函数转到 IoC 容器来检索其依赖项，这是测试 Foo 实例能够正确实例化的唯一方法应用程序的实际运行时配置是实际构建它。

这在测试时会产生各种尴尬的副作用，因为在运行时工作的代码不一定在测试工具下工作。模拟不会这样做，因为真正的配置是我们需要测试的东西，而不是一些测试时的设置。

这个问题的根源是 @Jon 已经指出的差异：通过构造函数注入依赖项是声明性的，而第二个版本使用命令式服务定位器模式。

如果仔细使用，IoC 容器可以静态分析应用程序的运行时配置，而无需实际创建所涉及组件的任何实例。许多流行的容器都提供了一些变体； Microsoft.Composition 是面向 .NET 4.5 Web 和 Metro 风格应用程序的 MEF 版本，在 wiki 文档中提供了 CompositionAssert 示例。使用它，您可以编写如下代码：（

 // Whatever you use at runtime to configure the container
var container = CreateContainer();

CompositionAssert.CanExportSingle<Foo>(container);

请参阅 this示例）。

通过在测试时验证应用程序的组合根，您可能会发现一些错误，否则这些错误可能会在稍后的过程中漏掉。

希望这是对该主题的这组全面答案的有趣补充！

Answer 8

在我的上一个项目中，我同时使用了两者。
我使用依赖注入来实现单元可测试性。我使用服务定位器来隐藏实现并依赖于我的 IoC 容器。是的！一旦你使用了 IoC 容器（Unity、Ninject、Windsor Castle），你就会依赖它。一旦它过时或者由于某种原因您想要交换它，您将/可能需要更改您的实现 - 至少是组合根。但服务定位器抽象了该阶段。

你怎么能不依赖你的 IoC 容器呢？您要么需要自己包装它（这是一个坏主意），要么使用服务定位器来配置 IoC 容器。因此，您将告诉服务定位器获取您需要的接口，并且它将调用配置为检索该接口的 IoC 容器。

就我而言，我使用 ServiceLocator，这是一个框架组件。我将 Unity 用于我的 IoC 容器。如果将来我需要将 IoC 容器替换为 Ninject，我需要做的就是配置我的服务定位器以使用 Ninject 而不是 Unity。轻松迁移。

这是一篇很棒的文章，解释了这种情况；
http://www.johandekoning .nl/index.php/2013/03/03/dont-wrap-your-ioc-container/

Answer 9

我认为两者一起工作。

依赖注入意味着您将一些依赖类/接口推送到消费类（通常是它的构造函数）。这通过接口将两个类解耦，并且意味着使用类可以使用多种类型的“注入依赖项”实现。

服务定位器的作用是将您的实施整合在一起。您可以在程序开始时通过一些引导程序设置服务定位器。引导是将一种实现类型与特定抽象/接口相关联的过程。它是在运行时为您创建的。 （基于您的配置或引导程序）。如果您没有实现依赖注入，那么使用服务定位器或 IOC 容器将非常困难。

Answer 10

以下简单的概念让我更清楚地理解了 Service Locator 和 DI Container 之间的区别：

• Service Locator 用于消费者，它通过 ID 从某些存储中拉取服务根据直接消费者的请求

• DI容器 位于外部某个地方，它从某些存储中获取服务并将它们推送给消费者（无论是通过构造函数还是通过方法）

但是，我们只能在具体消费者使用的上下文中讨论它们之间的差异。当Service Locator和DI Container用于组合根时，它们几乎是相似的。

Answer 11

注意：我没有完全回答这个问题。但我觉得这对于依赖注入模式的新学习者来说很有用，他们对它与 服务定位器（反）模式 碰巧偶然发现此页面。

我知道服务定位器（现在似乎被视为反模式）和依赖注入模式之间的区别，并且可以理解每种模式的具体示例，但我对构造函数内显示服务定位器的示例感到困惑（假设我们'正在进行构造函数注入）。

“服务定位器”通常既用作模式的名称，又用作引用该模式中使用的对象（假设也是）的名称，以在不使用 new 运算符的情况下获取对象。现在，相同类型的对象也可以用在 组合根 执行依赖注入，这就是令人困惑的地方。

需要注意的是，您可能在 DI 构造函数内使用服务定位器对象，但您没有使用“服务定位器模式”。如果有人将其称为 IoC 容器对象，那么就不会那么令人困惑，因为您可能已经猜到它们本质上做了相同的事情（如果我错了，请纠正我）。

无论它是被称为服务定位器（或只是定位器），还是作为 IoC 容器（或只是容器），正如您所猜测的那样，都没有区别，它们可能指的是相同的抽象（如果我错了，请纠正我） ）。只是将其称为服务定位器表明将服务定位器反模式与依赖注入模式一起使用。

恕我直言，将其命名为“定位器”而不是“位置”或“定位”，有时也会导致人们认为文章中的服务定位器指的是服务定位器容器，而不是服务定位器（反）模式，特别是当有一个称为依赖注入而不是依赖注入的相关模式时。

Answer 12

在这种过于简化的情况下，没有区别，它们可以互换使用。
然而，现实世界的问题并不那么简单。假设 Bar 类本身有另一个名为 D 的依赖项。在这种情况下，您的服务定位器将无法解析该依赖项，您必须在 D 类中实例化它；因为实例化它们的依赖关系是类的责任。如果 D 类本身有其他依赖项，情况会变得更糟，并且在现实情况下，它通常会变得比这更复杂。在这种情况下，DI 是比 ServiceLocator 更好的解决方案。

Answer 13

服务定位器和依赖注入都是遵循依赖倒置原则的对象访问模式实现。

---

依赖注入是[静态/全局]对象访问模式

服务定位器是[动态]对象访问模式

---

如果您需要处理[动态结构]，例如[ui树]或任何[分形设计的应用程序]，您可能需要服务定位器。

示例：

• React 的 createContext/useContext
• 提供/注入
• Angular 的 Vue Providers

如果您只想从类中获取一个实例，而不关心应用程序的层次结构和位置对于该层次结构中的实例，您应该使用 DI。

示例：

• C#/Java 服务定位器中的注释

---

当您在运行前不知道服务的实际提供者时，可以使用

。当您知道静态容器提供该服务时，就会使用 DI。

---

服务定位器模式更像是模块级别依赖提供者，而DI是全局级别。

当有一个子模块声明应由其父模块提供的服务的依赖关系而不是静态解析类型（singleton/transient/静态范围）。

它可以通过 DI 的范围注入模式来实现，而范围是由应用程序的模块结构/关系定义的。

---

个人建议：

1. 尽可能使用DI。
2. 如果您必须处理分形结构中的动态/运行时服务解析，请使用服务定位器。
3. 将服务定位器封装为作用域 DI，例如：@inject({scope: 'contextual' })
4. 通过接口而不是类/构造函数来定位服务。

---

详细信息：https://learn.microsoft .com/zh-cn/dotnet/core/extensions/dependency-injection-guidelines#recommendations

Answer 14

依赖注入和服务定位器之间有什么区别（如果有）？两种模式都擅长实现依赖倒置原则。服务定位器模式在现有代码库中更易于使用，因为它使整体设计更加宽松，而无需强制更改公共接口。出于同样的原因，基于服务定位器模式的代码的可读性低于基于依赖项注入的等效代码。

依赖注入模式清楚地表明了类（或方法）将具有哪些依赖项的签名。因此，生成的代码更加干净且更具可读性。

Answer 15

DI 容器是服务定位器的超集。它可用于定位服务，并具有组装（连接）依赖项注入的附加功能。

Answer 16

郑重声明

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

除非您确实需要一个接口（该接口由多个类使用），否则您不得使用它。在这种情况下，IBar 允许使用任何实现它的服务类。但是，通常，该接口将由单个类使用。

为什么使用接口是一个坏主意？因为调试起来确实很困难。

例如，假设实例“bar”失败，问题：哪个类失败？ 我应该修复哪些代码？一个简单的视图，它会导致一个接口，我的路就到此为止了。

相反，如果代码使用硬依赖项，则很容易调试错误。

//Foo Needs an IBar
public class Foo
{
  private BarService bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

如果“bar”失败，那么我应该检查并启动 BarService 类。