这两种模式似乎都是控制反转原理的实现。也就是说，一个对象不应该知道如何构造它的依赖项。
依赖注入(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容器只是另一种类型的服务定位器吗?当我们有很多依赖时，我们使用依赖注入容器，这是一个细微的差别吗?
Martin Fowler说:
使用服务定位器，应用程序类将显式地通过
消息发送给定位器。对于注入，没有显式的请求，
服务出现在应用程序类中——因此是
控制。
简而言之:服务定位器和依赖注入只是依赖反转原理的实现。
重要的原则是“依赖抽象，而不是具象”。这将使你的软件设计“松散耦合”、“可扩展”、“灵活”。
您可以使用最适合您需要的一种。对于拥有庞大代码库的大型应用程序，您最好使用服务定位器，因为依赖注入将需要对代码库进行更多更改。
你可以查看这篇文章:依赖倒置:服务定位器或依赖注入
还有经典的:Martin Fowler的控制容器反转和依赖注入模式
设计可重用类作者:Ralph E. Johnson和Brian Foote
然而，让我大开眼界的是:ASP。NET MVC:解析还是注入?这就是问题所在，迪诺·埃斯波西托著
郑重声明
//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;
}
//...
}
如果“酒吧”失败，那么我应该检查和杉木类BarService。
添加的一个原因是，受到我们上周为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根，您可以潜在地捕捉到一些错误，否则这些错误可能会在后面的测试过程中遗漏。
希望这是一个有趣的补充，否则这个主题的答案是全面的!
注意:我并不是在回答这个问题。但是我觉得这对于那些对依赖注入模式和服务定位器(反)模式感到困惑的新学习者来说是有用的。
我知道服务定位器(它现在似乎被视为反模式)和依赖注入模式之间的区别，并且可以理解每种模式的具体示例，但我对在构造函数内部显示服务定位器的示例感到困惑(假设我们正在进行构造函数注入)。
“Service Locator”通常既用作模式的名称，也用作该模式中使用的对象的名称(假设也是)，以在不使用new操作符的情况下获取对象。现在，同样类型的对象也可以在组合根上用于执行依赖项注入，这就是产生混淆的地方。
需要注意的一点是，您可以在DI构造函数中使用服务定位器对象，但您没有使用“服务定位器模式”。如果将它引用为IoC容器对象，就不会那么令人困惑，因为您可能已经猜到它们本质上做的是相同的事情(如果我错了，请纠正我)。
无论它被称为服务定位器(或仅仅是定位器)，还是IoC容器(或仅仅是容器)，正如您所猜测的那样，它们都可能引用相同的抽象(如果我说错了，请纠正我)。只是称其为服务定位器表明将服务定位器反模式与依赖注入模式一起使用。
以我之见，将其命名为“定位器”而不是“位置”或“定位”，有时也会导致人们认为文章中的服务定位器指的是服务定位器容器，而不是服务定位器(反)模式，特别是当有一个相关的模式叫做依赖注入而不是依赖注入时。
