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

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

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

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

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

> DI – 具体服务作为ctor param注入/抛出一个setter / throw接口注入(后者是什么意思？)
> ServiceLocator – 是一个知道应用程序可能需要的所有具体服务的组件.应用程序明确要求定位器提供具体服务.

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

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

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

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

确实,IoC与实现中的解耦接口密切相关,但我将其视为更一般的原则. This SO answer给出了一个非常好的概念解释.

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

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

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的示例中,MovieLister在使用DI时仅依赖于MovieFinder界面).
此外,其他人很容易使用您的组件 – 只需使用您提供的DI方式传递依赖关系.

使用服务定位器时,还会添加对服务定位器本身接口的依赖性.使用Locator的隔离接口,这可能不是问题.但是,对于组件的用户来说,也可能更难以满足组件的依赖关系,因为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.

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!