7

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

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

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

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

  1. DI - 具体服务作为 ctor 参数注入/抛出一个 setter/throw 接口注入（后者是什么意思？）

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

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

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

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

4

1 回答 1

4

IoC 是将应用程序与其使用的服务实现分离的概念。

确实，IoC 与将接口与实现解耦齐头并进，但我认为这是一个更普遍的原则。这个 SO answer很好地解释了这个概念。

至少有两种方法可以实现：
1）DI
2）ServiceLocator

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

定位器如何更直接？因为它显式地使用方法调用？

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

当有多个应用程序时，使用 DI 有什么好处？

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

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

如果列表器是我提供给其他人正在编写的应用程序的组件，那么差异就会出现。在这种情况下，我不太了解我的客户将使用的服务定位器的 API。每个客户可能都有自己不兼容的服务定位器。

于 2011-09-10T22:16:11.563 回答