dependency-injection - 验证我了解 IoC、Ioc 容器、DI 和服务定位器之间的区别

Question

阅读许多有关这三个成语之间差异的帖子。但是比较困惑，然后我遇到了这篇文章:
http://martinfowler.com/articles/injection.html

只是想看看我是否做对了。如果我错了，请纠正我。
请通知我更正和补充:

IoC-是概念 将应用程序与其使用的服务的实现分离。该应用程序包含对 Iservice 的引用，并且不负责实例化具体服务。

至少有两种方法可以实现:

迪 - 具体服务作为ctor参数注入(inject)/抛出setter/throw接口(interface)注入(inject)(后者是什么意思？)

服务定位 - 是一个组件，它知道应用程序可能需要的所有具体服务。应用程序明确要求定位器提供具体服务。

*IoC 容器实际上是一个控件的工厂(“提供者”)。

我对文章中的“何时更喜欢(1)或(2)”部分感到有些困惑。 有人可以用外行的话从他自己的经历中说出来吗？

“服务定位器由于其更直接的行为而略有优势。但是，如果您正在构建要在多个应用程序中使用的类，那么依赖注入(inject)是一个更好的选择。”--> 定位器如何更直接？因为它显式地使用方法调用？当有多个应用程序时，使用 DI 有什么好处？

Answer 1

IoC is the concept of decoupling an application from the implementation of a service it uses.

确实，IoC 与将接口(interface)与实现解耦密切相关，但我认为这是一个更普遍的原则。 This SO answer很好地解释了这个概念。

There are at least two way to achive so:
1) DI
2) ServiceLocator

我不会说服务定位器模式是控制反转的一个例子。恰恰相反 - 当您使用服务定位器时，您正在以主动方式获取所需的依赖项，没有其他人为您完成(与 DI 相反，容器为您处理依赖项，您只需要给它一个这样做的可能性 - 一个 setter ，一个构造函数参数或通过实现注入(inject)接口(interface)的方法)。

How is locator more straightforward ? because it uses method invocation explicitly?

我认为 Martin Fowler 指的是 IoC 的一般概念，如果您以前从未见过 IoC/DI 概念，可能会使代码更难理解。另一方面，使用 Service Locator 获取一些依赖关系的代码在第一次遇到时可能更容易掌握。

What is it better to use DI when there are multiple applications?

当您创建一个应该可重用的组件时，DI 的优势在于它不会使您的组件依赖于原始依赖项以外的任何其他内容(在 MF 的示例中，当使用 DI 时，MovieLister 仅依赖于 MovieFinder 接口(interface))。
此外，其他人使用您的组件非常容易 - 只需使用您提供的 DI 方法传递依赖项。

使用服务定位器时，您还添加了对服务定位器本身接口(interface)的依赖。使用定位器的隔离接口(interface)，这可能不是问题。但正如 MF 所写，组件的用户也可能更难满足组件的依赖关系:

The difference comes if the lister is a component that I'm providing to an application that other people are writing. In this case I don't know much about the APIs of the service locators that my customers are going to use. Each customer might have their own incompatible service locators.