阅读很多关于3个成语之间差异的帖子。但是更加困惑，然后我遇到了这篇文章： http://martinfowler.com/articles/injection.html
只是想看看我是否做对了。如果我错了，请纠正我。 请通知我更正和补充：
IoC-是将应用程序与其使用的服务实现分离的概念。该应用程序包含对Iservice的引用，并不具备实现具体服务的能力。
至少有两种方法可以实现：
DI - 具体服务作为ctor param注入/抛出一个setter / throw接口注入（后者意味着什么？）
ServiceLocator - 是一个知道应用程序可能需要的所有具体服务的组件。应用程序明确要求定位器提供具体服务。
* IoC容器实际上是一个控件'工厂（“提供者”）。
我对文章中的“何时更喜欢（1）或（2）”部分感到有些困惑。 有人可以用外行的话说出自己的经历吗？
“服务定位器由于其更直接的行为而略有优势。但是，如果要构建要在多个应用程序中使用的类，那么依赖注入是更好的选择。” - ＆gt;定位器如何更直接？因为它显式使用方法调用？当有多个应用程序时，使用DI有什么好处？
答案 0 :(得分：4)
IoC是将应用程序与其使用的服务实现分离的概念。
IoC确实与实现中的解耦接口密切相关，但我认为它是一个更通用的原则。 This SO answer对这个概念给出了非常好的解释。
至少有两种方法可以实现：
1）DI
2）ServiceLocator
我不会说服务定位器模式是控制反转的一个例子。恰恰相反 - 当您使用服务定位器时，您正在以主动方式获取所需的依赖项，没有其他人为您执行此操作（与DI相反，容器为您处理依赖项，您只需要给它一个这样做的可能性 - 一个setter，一个构造函数参数或者通过实现注入接口的方法）。
定位器如何更直接？因为它显式使用方法调用吗？
我认为Martin Fowler指的是IoC的一般概念，如果您从未见过以前使用的IoC / DI概念，可能会使代码更难理解。另一方面，使用Service Locator获取某些依赖关系的代码在第一次遇到时可能更容易掌握。
当有多个应用程序时，使用DI有什么好处？
当您创建一个应该可重用的组件时，DI的优势在于它不会使您的组件依赖于除原始依赖之外的任何其他内容（在MF的示例中，MovieLister仅依赖于MovieFinder接口）使用DI时。 此外，其他人很容易使用您的组件 - 只需使用您提供的DI方式传递依赖关系。
使用服务定位器时，还会在服务定位器本身的接口上添加依赖项。使用Locator的隔离接口，这可能不是问题。但是，对于组件的用户来说，也可能更难以满足组件的依赖关系，因为MF写道：
如果列表程序是我提供给其他人正在编写的应用程序的组件，则会产生差异。在这种情况下，我不太了解客户将要使用的服务定位器的API。每个客户可能都有自己不兼容的服务定位器。