控制反转vs依赖注入

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

例如，会话Bean接口定义ejbRemove, ejbPassivate (存储到二级存储)，以及 ejbActivate(从被动恢复状态)。你不能控制时间这些方法被调用，只是什么他们做的事。集装箱召唤我们，我们别这么说。

这就导致了framework和library的区别:

控制反转是一个关键的部分框架与框架的区别是什么图书馆。图书馆本质上是一个一组你可以调用的函数，这些日子通常组织成类。每次调用都要做一些工作将控制权返回给客户端。

我认为，DI是IOC的观点，意味着对象的依赖关系是倒置的:而不是它控制自己的依赖关系、生命周期……其他东西可以帮你。但是，正如你告诉我的DI by hands, DI不一定是IOC。我们仍然可以有DI，没有IOC。

然而，在本文中(来自pococapsule, C/ c++的另一个IOC框架)，它指出，由于IOC和DI, IOC容器和DI框架要比J2EE优越得多，因为J2EE将框架代码混合到组件中，因此它不是普通的旧Java/ c++对象(POJO/POCO)。

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

附加阅读，了解旧的基于组件的开发框架的问题，这导致了上面的第二篇论文:为什么和什么反转控制(档案链接)

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

当前回答

IoC概念最初出现在过程式编程时代。因此，从历史背景来看，IoC讨论了控制流所有权的倒置，即谁拥有以所需顺序调用函数的责任——无论是函数本身还是应该将其倒置到某个外部实体。

However once the OOP emerged, people began to talk about IoC in OOP context where applications are concerned with object creation and their relationships as well, apart from the control-flow. Such applications wanted to invert the ownership of object-creation (rather than control-flow) and required a container which is responsible for object creation, object life-cycle & injecting dependencies of the application objects thereby eliminating application objects from creating other concrete object.

从这个意义上讲，DI与IoC不同，因为它不是关于控制流的，但是它是一种Io*，即对象创建的所有权倒置。

我解释DI和IoC的方式有什么问题?

2019-07-20 19:10:52

其他回答

控制反转是一种设计范式，其目标是为应用程序的目标组件提供更多的控制，即完成工作的组件。依赖注入是一种模式，用于创建其他对象所依赖的对象实例，而在编译时不知道将使用哪个类来提供该功能。

实现控制反转有几种基本技术。这些都是:

使用工厂模式使用服务定位器模式使用任何给定类型的依赖注入: 1).构造函数注入 2). setter注入 3).接口注入

2016-05-12 04:25:12

IOC(控制反转)基本上是一种设计模式概念，它删除依赖关系并将它们解耦，使流非线性，并让容器/或另一个实体管理依赖关系的供应。它实际上遵循了好莱坞的原则“不要打电话给我们，我们会打电话给你”。总结一下不同点。

控制反转:这是一个通用术语，用于解耦依赖关系并委托它们的供应，这可以通过几种方式实现(事件，委托等)。

依赖注入:—DI是IOC的一种子类型，通过构造函数注入、setter注入或方法注入实现。

下面的文章对此进行了非常简洁的描述。