我了解 IoC、Ioc Container、DI 和服务定位器之间的区别
阅读了很多关于这 3 个习语之间差异的文章。但更困惑的是，然后我遇到了这篇文章： http://martinfowler.com/articles/injection.html
只是想看看我是否得到了这个正确的。如果我错了，请纠正我。 请通知我更正和补充：
IoC-是将应用程序与其使用的服务的实现分离的概念。该应用程序包含对 Iservice 的引用，并且不负责实例化具体服务。
至少有两种方法可以实现：
DI - 具体服务作为 ctor param/throw 注入 setter/throw 接口注入（后者是什么意思？< /strong>)
- < p>ServiceLocator - 是一个知道应用程序可能需要的所有具体服务的组件。应用程序明确地向定位器请求具体服务。
*IoC 容器实际上是一个控件工厂（“提供者”）。
我对文章中的“何时选择（1）或（2）”部分感到有点困惑。 有人可以用外行的话从他自己的经验中看出吗？
“服务定位器由于其更直接的行为而具有轻微的优势。但是，如果您正在构建要在多个应用程序中使用的类，那么依赖注入是更好的选择。”-->定位器如何更简单？因为它显式地使用方法调用？当有多个应用程序时，使用 DI 哪个更好？
read many posts about the difference between the 3 idioms. But got more confused, then I ran into this article:
http://martinfowler.com/articles/injection.html
just want to see if I got this right. please correct me if I'm wrong.
Please notify me of correction and additions:
IoC- is the concept of decoupling an application from the implementation of a service it uses. The application contain a ref to Iservice and is not incharge of instanciating the concrete service.
There are at least two way to achive so:
DI - The concrete service is injected as a ctor param/throw a setter/throw interface injection (what does the latter mean?)
ServiceLocator - is a component that knows all the concrete services the application may need. The application explicitly asks for the concrete service from the Locator.
*IoC container is actualy a controls' factory ("provider").
I got a bit confused by the "when to prefer (1) or (2)" part in the article. could someone please tell from his own experience in a layman words ?
"Service Locator has a slight edge due to its more straightforward behavior. However if you are building classes to be used in multiple applications then Dependency Injection is a better choice."--> How is locator more straightforward ? because it uses method invocation explicitly ? What is it better to use DI when there are multiple applications?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
确实，IoC 与将接口与实现解耦密切相关，但我将其视为更普遍的原则。 这个答案很好地解释了这个概念。
我不会说服务定位器模式是控制反转的一个例子。恰恰相反 - 当您使用服务定位器时，您正在以主动方式获取所需的依赖项，没有其他人为您做这件事（与 DI 相反，容器为您处理依赖项，您只需给它一个这样做的可能性 - 设置器、构造函数参数或通过实现注入接口的方法）。
我认为 Martin Fowler 指的是 IoC 的一般思想，如果您以前从未见过使用过 IoC/DI 概念，则可能会使代码更难理解。另一方面，使用服务定位器获取某些依赖项的代码在第一次遇到时可能更容易掌握。
当您创建一个应该可重用的组件时，DI 的优点是它不会使您的组件依赖于除原始依赖项之外的任何其他内容（在 MF 的示例中，当使用 DI 时，MovieLister 仅依赖于 MovieFinder 接口） ）。
此外，其他人使用您的组件也很容易 - 只需使用您提供的 DI 方式传递依赖项即可。
使用服务定位器时，您还可以添加对服务定位器本身的接口的依赖项。有了定位器的隔离接口，这可能不是问题。但组件的用户也可能更难满足组件的依赖关系，正如 MF 所写：
It is true that IoC goes hand in hand with decoupling interfaces from implementations, but I see it as a more general principle. This SO answer gives a very good explanation of the concept.
I wouldn't say that the Service Locator pattern is an example of Inversion of Control. Quite the opposite - when you are using the Service Locator, you are acquiring the required dependencies in active way, nobody else does it for you (contrary to the DI, where the container handles the dependencies for you, you just have to give it a possibility of doing so - a setter, a constructor parameter or by implementing method of injection interface).
I think that Martin Fowler is referring to the general idea of IoC that may make the code harder to understand if you've never seen the IoC/DI concept used before. On the other hand, the code using Service Locator to acquire some dependencies may be easier to grasp on first encounter.
When you are creating a component that is supposed to be reusable, the advantage of DI is that it doesn't make your component dependent on anything else than the original dependency (in MF's example, the MovieLister depends only on the MovieFinder interface when using DI).
Also, it is quite easy for others to use your component - the just have to pass the dependencies using the means of DI you provided.
When using the Service Locator, you also add dependency on the interface of the Service Locator itself. With segregated interface for the Locator, that may not be a problem. But it may also be harder for users of your component to satisfy the dependencies of your component, as MF writes: