根据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不仅仅是对象或程序员与框架之间控制的反转。
DIP vs DI vs IoC
[依赖倒置原则(DIP)]是SOLID[About]的一部分，它要求你使用抽象而不是实现
依赖注入(DI) -使用聚合而不是组合[关于]在这种情况下，外部对象负责内部的逻辑。哪一种方法使您拥有更动态和更可测试的方法
class A {
B b
//injecting B via constructor
init(b: B) {
self.b = b
}
}
控制反转(IoC)是一个非常高级的定义，它更多地是关于控制流的。最好的例子是控制反转(IoC)容器或框架。例如，GUI是一个框架，你没有一个控制，你能做的一切只是实现框架的接口，当一些动作发生在框架中时，它会被调用。这样，控制权就从应用程序转移到了正在使用的框架中
DIP +
class A {
IB ib
init(ib: IB) {
self.ib = ib
}
}
你也可以使用:
(工厂方法)
(服务定位器)
[ioc容器(框架)]
更复杂的例子
多层/模块结构中的依赖规则
伪代码:
interface InterfaceInputPort {
func input()
}
interface InterfaceOutputPort {
func output()
}
class A: InterfaceOutputPort {
let inputPort = B(outputPort: self)
func output() {
print("output")
}
}
class B: InterfaceInputPort {
let outputPort: InterfaceOutputPort
init(outputPort: InterfaceOutputPort) {
self.outputPort = outputPort
}
func input() {
print("input")
}
}
控制反转(IoC)模式是关于提供任何类型的回调，它“实现”和/或控制反应，而不是我们自己直接操作(换句话说，反转和/或重定向控制到外部处理程序/控制器)。
例如，不是让应用程序调用库(也称为工具包)提供的实现，而是库和/或框架调用应用程序提供的实现。
依赖注入(DI)模式是IoC模式的一个更具体的版本，其中实现通过构造函数/设置器/服务查找传递到对象中，对象将“依赖”这些以正确地行为。
每个DI实现都可以被认为是IoC，但不应该称之为IoC，因为实现依赖注入比实现回调更难(不要使用通用术语“IoC”来降低产品的价值)。
例如，不使用DI的IoC将是Template模式，因为实现只能通过子类化来更改。
依赖注入框架被设计为使用依赖注入，并且可以定义接口(或Java中的注释)以方便在实现中传递。
IoC容器是可以在编程语言之外工作的依赖注入框架。在某些情况下，您可以在元数据文件(例如XML)中配置要使用的实现，这是侵入性较小的。有一些可以做IoC，这通常是不可能的，比如在切入点注入实现。
参见Martin Fowler的文章。
