根据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不仅仅是对象或程序员与框架之间控制的反转。
DI和IOC是两种主要侧重于提供组件之间的松耦合的设计模式，或者简单地说，这是一种解耦对象之间传统依赖关系的方法，这样对象之间就不会紧密相连。
通过下面的例子，我试图解释这两个概念。
以前我们是这样写代码的
Public MyClass{
DependentClass dependentObject
/*
At somewhere in our code we need to instantiate
the object with new operator inorder to use it or perform some method.
*/
dependentObject= new DependentClass();
dependentObject.someMethod();
}
使用Dependency注入，依赖注入器将负责对象的实例化
Public MyClass{
/* Dependency injector will instantiate object*/
DependentClass dependentObject
/*
At somewhere in our code we perform some method.
The process of instantiation will be handled by the dependency injector
*/
dependentObject.someMethod();
}
上述将控件交给其他容器(例如容器)进行实例化和注入的过程可以称为控制反转，IOC容器为我们注入依赖项的过程可以称为依赖项注入。
IOC是程序控制流颠倒过来的原则:不是由程序员控制程序的流，而是由程序通过减少程序员的开销来控制流程。程序用来注入依赖的过程称为DI
这两个概念一起工作为我们提供了一种编写更加灵活、可重用和封装的代码的方法，这使得它们在设计面向对象的解决方案时成为重要的概念。
也推荐阅读。
什么是依赖注入?
你也可以在这里查看我的一个类似的答案
控制反转和依赖注入的区别
