这两种模式似乎都是控制反转原理的实现。也就是说，一个对象不应该知道如何构造它的依赖项。
依赖注入(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容器只是另一种类型的服务定位器吗?当我们有很多依赖时，我们使用依赖注入容器，这是一个细微的差别吗?
添加的一个原因是，受到我们上周为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根，您可以潜在地捕捉到一些错误，否则这些错误可能会在后面的测试过程中遗漏。
希望这是一个有趣的补充，否则这个主题的答案是全面的!
在我的上一个项目中，我两者都用了。
我使用依赖注入进行单元测试。我使用服务定位器来隐藏实现并依赖于我的IoC容器。是的!一旦你使用了IoC容器(Unity, Ninject, Windsor Castle)，你就依赖于它了。一旦它过时了，或者由于某种原因你想要交换它，你将/可能需要改变你的实现-至少是组合根。但是服务定位器抽象了这个阶段。
如何不依赖于IoC容器?您要么需要自己包装它(这是一个坏主意)，要么使用Service Locator来配置IoC容器。因此，您将告诉Service Locator获取所需的接口，它将调用IoC容器，该容器被配置为检索该接口。
在我的例子中，我使用ServiceLocator，它是一个框架组件。我使用Unity作为IoC容器。如果在未来我需要交换我的IoC容器与Ninject，我所需要做的是配置我的服务定位器使用Ninject而不是Unity。容易迁移。
这里有一篇很棒的文章解释了这种情况;
http://www.johandekoning.nl/index.php/2013/03/03/dont-wrap-your-ioc-container/
