验证我理解IoC,Ioc容器,DI和服务定位器之间的区别

Question

阅读很多关于3个成语之间差异的帖子.但是更加困惑,然后我遇到了这篇文章:http: //martinfowler.com/articles/injection.html

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

IoC-是将应用程序与其使用的服务的实现分离的概念.该应用程序包含对Iservice的引用,并不具备实现具体服务的能力.

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

*IoC容器实际上是控件的工厂("提供者").

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

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

Answer 1

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

确实，IoC 与将接口与实现解耦密切相关，但我将其视为更普遍的原则。这个 SO 答案很好地解释了这个概念。

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

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

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

我认为 Martin Fowler 指的是 IoC 的一般思想，如果您以前从未见过使用过 IoC/DI 概念，则可能会使代码更难理解。另一方面，使用服务定位器获取某些依赖项的代码在第一次遇到时可能更容易掌握。

当有多个应用程序时，使用 DI 哪个更好？

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

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

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