控制反转与依赖注入 [英] Inversion of Control vs Dependency Injection

问题描述

根据 Martin Fowler 撰写的论文，控制反转是控制的原理程序流是颠倒的:不是程序员控制程序流，而是外部源(框架、服务、其他组件)控制它.就像我们将某些东西插入其他东西一样.他提到了一个关于 EJB 2.0 的例子:

According to the paper written by Martin Fowler, inversion of control is the principle where the control flow of a program is inverted: instead of the programmer controlling the flow of a program, the external sources (framework, services, other components) take control of it. It's like we plug something into something else. He mentioned an example about EJB 2.0:

例如Session Bean接口定义 ejbRemove、ejbPassivate(存储到二级存储)，和ejbActivate(从被动恢复状态).你无法控制何时这些方法被调用，只是什么他们是这样.容器呼唤我们，我们不要叫它.

For example the Session Bean interface defines ejbRemove, ejbPassivate (stored to secondary storage), and ejbActivate (restored from passive state). You don't get to control when these methods are called, just what they do. The container calls us, we don't call it.

这就导致了框架和库的区别:

This leads to the difference between framework and library:

控制反转是关键部分是什么让框架不同于图书馆.图书馆本质上是一个您可以调用的一组函数，这些天通常被组织成类.每次调用都会做一些工作将控制权返回给客户端.

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

我认为，DI 是 IOC 的观点，意味着对象的依赖关系是颠倒的:它不是控制自己的依赖关系，生命周期......其他东西为你做.但是，正如您告诉我有关手动 DI 的那样，DI 不一定是 IOC.我们仍然可以有 DI 而没有 IOC.

I think, the point of view that DI is IOC, means the dependency of an object is inverted: instead of it controlling its own dependencies, life cycle... something else does it for you. But, as you told me about DI by hands, DI is not necessarily IOC. We can still have DI and no IOC.

然而，在这篇论文中(来自pococapsule，另一个用于C/C++的IOC框架)，它表明由于IOC和DI，IOC容器和DI框架要优于J2EE，因为J2EE混合了框架代码到组件中，因此不会使其成为普通的旧 Java/C++ 对象 (POJO/POCO).

However, in this paper (from the pococapsule, another IOC Framework for C/C++), it suggests that because of IOC and DI, the IOC containers and DI frameworks are far more superior to J2EE, since J2EE mixes the framework code into the components, thus not making it Plain Old Java/C++ Object (POJO/POCO).

依赖注入模式以外的控制容器反转(存档链接)

补充阅读以了解旧的基于组件的开发框架有什么问题，这导致上面的第二篇论文:控制反转的原因和内容(存档链接)

Additional reading to understand what's the problem with old Component-Based Development Framework, which leads to the second paper above: Why and what of Inversion of Control (Archive link)

我的问题:IOC 和 DI 到底是什么?我很迷惑.基于 pococapsule，IOC 不仅仅是对象或程序员与框架之间的控制反转.

My Question: What exactly is IOC and DI? I am confused. Based on pococapsule, IOC is something more significant than just inversion of the control between objects or programmers and frameworks.

推荐答案

IoC 是一个通用术语，意思是不是让应用程序调用库提供的实现(也称为工具包)，框架调用应用程序提供的实现.

IoC is a generic term meaning that rather than having the application call the implementations provided by a library (also know as toolkit), a framework calls the implementations provided by the application.

DI 是 IoC 的一种形式，其中实现通过构造函数/设置器/服务查找传递到对象中，对象将依赖"它们以正确运行.

DI is a form of IoC, where implementations are passed into an object through constructors/setters/service lookups, which the object will 'depend' on in order to behave correctly.

不使用 DI 的 IoC，例如模板模式，因为实现只能通过子类进行更改.

IoC without using DI, for example would be the Template pattern because the implementation can only be changed through sub-classing.

DI 框架旨在利用 DI 并且可以定义接口(或 Java 中的注解)，以便于在实现中传递.

DI frameworks are designed to make use of DI and can define interfaces (or Annotations in Java) to make it easy to pass in the implementations.

IoC 容器是可以在编程语言之外工作的 DI 框架.在某些情况下，您可以配置在侵入性较小的元数据文件(例如 XML)中使用哪些实现.使用一些您可以执行通常不可能的 IoC，例如在 切入点 处注入实现.

IoC containers are DI frameworks that can work outside of the programming language. In some you can configure which implementations to use in metadata files (e.g. XML) which are less invasive. With some you can do IoC that would normally be impossible like inject an implementation at pointcuts.

另见这篇Martin Fowler 的文章.

这篇关于控制反转与依赖注入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！