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

Question

阅读关于3个惯用语之间区别的许多帖子。但变得更加困惑，然后我碰到这篇文章： http://martinfowler.com/articles/injection.html

只是想看看我是否得到这个权利。如果我错了，请纠正我。 请通知我修正和补充：

IOC-是脱钩它使用一个服务的实现应用程序的概念。该应用程序包含Iservice的参考资料，并且不需要实例化具体服务。

有至少两个才达到这样的方式：

1. DI - 混凝土业务注入的构造函数PARAM /扔一个setter /扔接口注入（什么后者意味着什么呢？）

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

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

我对文章中的“何时偏好（1）或（2）”部分有些困惑。 有人可以从他自己的经验中看出一个外行人的话吗？

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

Answer 1

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

确实，IoC与解耦接口与实现脱钩，但我认为它是一个更一般的原则。 This SO answer给出了这个概念的很好的解释。

有才达到这样的至少两种方式：
1）DI
2）的ServiceLocator

我不会说的服务定位器模式是反向控制的一个例子。恰恰相反 - 当你使用服务定位器时，你正以主动的方式获得所需的依赖关系，没有人为你做这件事（与容器为你处理依赖关系的DI相反，你只需要给它一个这样做的可能性 - setter，构造函数参数或实现注入接口的方法）。

定位器如何更直接？因为它明确使用方法调用？

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

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

当你创建一个被认为是可重用的组件，DI的优点是它不会使你的组件依赖于任何东西比原来依赖其他人（在MF的例子中，MovieLister只取决于使用DI时的MovieFinder接口）。 另外，其他人使用你的组件非常容易 - 只需使用你提供的DI的方式传递依赖关系。

使用服务定位器时，还需要添加对服务定位器本身接口的依赖性。使用定位器的隔离界面，这可能不成问题。但它也可能难以为组件的用户，以满足您的组件的依赖，为MF写道：

的差别来，如果李斯特是我提供给应用程序，其他人是组件写作。在这种情况下，我对客户要使用的服务定位器的API知之甚少。每个客户可能都有自己的不兼容的服务定位器。