这两种模式似乎都是控制反转原理的实现。也就是说，一个对象不应该知道如何构造它的依赖项。
依赖注入(DI)似乎使用构造函数或setter来“注入”它的依赖项。
使用构造函数注入的例子:
//Foo Needs an IBar
public class Foo
{
private IBar bar;
public Foo(IBar bar)
{
this.bar = bar;
}
//...
}
Service Locator似乎使用了一个“容器”，它连接了它的依赖项并给了foo它的bar。
使用Service Locator的例子:
//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容器只是另一种类型的服务定位器吗?当我们有很多依赖时，我们使用依赖注入容器，这是一个细微的差别吗?
注意:我并不是在回答这个问题。但是我觉得这对于那些对依赖注入模式和服务定位器(反)模式感到困惑的新学习者来说是有用的。
我知道服务定位器(它现在似乎被视为反模式)和依赖注入模式之间的区别，并且可以理解每种模式的具体示例，但我对在构造函数内部显示服务定位器的示例感到困惑(假设我们正在进行构造函数注入)。
“Service Locator”通常既用作模式的名称，也用作该模式中使用的对象的名称(假设也是)，以在不使用new操作符的情况下获取对象。现在，同样类型的对象也可以在组合根上用于执行依赖项注入，这就是产生混淆的地方。
需要注意的一点是，您可以在DI构造函数中使用服务定位器对象，但您没有使用“服务定位器模式”。如果将它引用为IoC容器对象，就不会那么令人困惑，因为您可能已经猜到它们本质上做的是相同的事情(如果我错了，请纠正我)。
无论它被称为服务定位器(或仅仅是定位器)，还是IoC容器(或仅仅是容器)，正如您所猜测的那样，它们都可能引用相同的抽象(如果我说错了，请纠正我)。只是称其为服务定位器表明将服务定位器反模式与依赖注入模式一起使用。
以我之见，将其命名为“定位器”而不是“位置”或“定位”，有时也会导致人们认为文章中的服务定位器指的是服务定位器容器，而不是服务定位器(反)模式，特别是当有一个相关的模式叫做依赖注入而不是依赖注入时。
注意:我并不是在回答这个问题。但是我觉得这对于那些对依赖注入模式和服务定位器(反)模式感到困惑的新学习者来说是有用的。
我知道服务定位器(它现在似乎被视为反模式)和依赖注入模式之间的区别，并且可以理解每种模式的具体示例，但我对在构造函数内部显示服务定位器的示例感到困惑(假设我们正在进行构造函数注入)。
“Service Locator”通常既用作模式的名称，也用作该模式中使用的对象的名称(假设也是)，以在不使用new操作符的情况下获取对象。现在，同样类型的对象也可以在组合根上用于执行依赖项注入，这就是产生混淆的地方。
需要注意的一点是，您可以在DI构造函数中使用服务定位器对象，但您没有使用“服务定位器模式”。如果将它引用为IoC容器对象，就不会那么令人困惑，因为您可能已经猜到它们本质上做的是相同的事情(如果我错了，请纠正我)。
无论它被称为服务定位器(或仅仅是定位器)，还是IoC容器(或仅仅是容器)，正如您所猜测的那样，它们都可能引用相同的抽象(如果我说错了，请纠正我)。只是称其为服务定位器表明将服务定位器反模式与依赖注入模式一起使用。
以我之见，将其命名为“定位器”而不是“位置”或“定位”，有时也会导致人们认为文章中的服务定位器指的是服务定位器容器，而不是服务定位器(反)模式，特别是当有一个相关的模式叫做依赖注入而不是依赖注入时。
添加的一个原因是，受到我们上周为MEF项目编写的文档更新的启发(我帮助构建MEF)。
一旦应用程序可能由数千个组件组成，就很难确定任何特定的组件是否可以正确地实例化。通过“正确实例化”，我的意思是在这个基于Foo组件的例子中，IBar的实例和将是可用的，并且提供它的组件将:
有必要的依赖关系，
不涉及任何无效的依赖周期，以及
在MEF的情况下，只提供一个实例。
在你给出的第二个例子中，构造函数去IoC容器检索它的依赖项，你可以测试Foo实例能够正确地实例化应用程序的实际运行时配置的唯一方法是实际构造它。
这在测试时产生了各种尴尬的副作用，因为在运行时可以工作的代码不一定能在测试工具下工作。模拟是不行的，因为我们需要测试的是真正的配置，而不是一些测试时的设置。
这个问题的根源是@Jon已经指出的区别:通过构造函数注入依赖是声明性的，而第二个版本使用命令式的Service Locator模式。
IoC容器，如果使用得当，可以静态地分析应用程序的运行时配置，而无需实际创建任何相关组件的实例。许多流行的容器提供了这方面的一些变化;微软。Composition是针对。net 4.5 web和Metro风格应用程序的MEF版本，在wiki文档中提供了一个compostionassert示例。使用它，你可以编写如下代码:
// Whatever you use at runtime to configure the container
var container = CreateContainer();
CompositionAssert.CanExportSingle<Foo>(container);
(请看这个例子)。
通过在测试时验证应用程序的Composition根，您可以潜在地捕捉到一些错误，否则这些错误可能会在后面的测试过程中遗漏。
希望这是一个有趣的补充，否则这个主题的答案是全面的!
A class using constructor DI indicates to consuming code that there are dependencies to be satisfied. If the class uses the SL internally to retrieve such dependencies, the consuming code is not aware of the dependencies. This may on the surface seem better, but it is actually helpful to know of any explicit dependencies. It is better from an architectural view. And when doing testing, you have to know whether a class needs certain dependencies, and configure the SL to provide appropriate fake versions of those dependencies. With DI, just pass in the fakes. Not a huge difference, but it is there.
不过，DI和SL可以一起工作。为常见的依赖项(如设置、记录器等)设置一个中心位置是很有用的。给定一个使用这种deps的类，您可以创建一个接收deps的“真实”构造函数，以及一个从SL检索并转发给“真实”构造函数的默认(无参数)构造函数。
EDIT:当然，当您使用SL时，您将向该组件引入一些耦合。这是具有讽刺意味的，因为这种功能的思想是鼓励抽象和减少耦合。这些关注点是可以平衡的，这取决于您需要在多少地方使用SL。如果按照上面建议的那样做，只是在默认的类构造函数中。
