当第一次遇到控制反转（IoC）时，它可能非常令人困惑。
这是怎么一回事？它解决了哪个问题？什么时候使用合适，什么时候不合适？
当前回答
控制反转，（或IoC），是关于获得自由（你结婚了，失去了自由，你被控制了。你离婚了，你刚刚实现了控制反转。这就是我们所说的“脱钩”。好的计算机系统阻碍了一些非常亲密的关系。)更灵活（你办公室的厨房只供应干净的自来水，这是你想喝水时的唯一选择。你的老板通过安装一台新的咖啡机实现了控制反转。现在你可以灵活选择自来水或咖啡。)和更少的依赖性（你的伴侣有工作，你没有工作，你在经济上依赖你的伴侣，所以你受到控制。你找到了工作，你实现了控制反转。良好的计算机系统鼓励依赖。）
当你使用台式电脑时，你已经从（或者说，被控制）了。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个写得不好的软件会让你更加痛苦。如果你把桌面换成笔记本电脑，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是由电脑控制。
通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。
考虑到上述想法。我们仍然错过了IoC的一个关键部分。在IoC的场景中，软件/对象使用者是一个复杂的框架。这意味着您创建的代码不是自己调用的。现在让我们来解释一下为什么这种方式对web应用程序更有效。
假设您的代码是一组工作人员。他们需要造一辆车。这些工人需要一个地方和工具（软件框架）来制造汽车。一个传统的软件框架就像一个有很多工具的车库。因此，工人们需要自己制定计划，并使用工具来制造汽车。造一辆车不是一件容易的事，工人们很难做好计划并进行适当的合作。一个现代化的软件框架将像一个拥有所有设施和管理人员的现代化汽车工厂。工人不必制定任何计划，管理者（框架的一部分，他们是最聪明的人，制定了最复杂的计划）将帮助协调，以便工人知道何时完成他们的工作（框架调用您的代码）。工人们只需要足够灵活地使用经理给他们的任何工具（通过使用依赖注入）。
尽管工人将项目管理的控制权交给了管理者（框架）。但有一些专业人士帮助是很好的。这就是IoC的真正来源。
具有MVC架构的现代Web应用程序依赖于框架来执行URL路由，并将控制器放置在适当的位置以供框架调用。
依赖注入和控制反转是相关的。依赖注入在微观层面，控制反转在宏观层面。为了完成一顿饭（实现IoC），你必须吃每一口（实现DI）。
其他回答
但我认为你必须非常小心。如果你过度使用这种模式，你会做出非常复杂的设计，甚至更复杂的代码。
就像这个例子中的TextEditor一样：如果你只有一个拼写检查器，那么可能真的没有必要使用IoC？除非你需要写单元测试之类的。。。
无论如何：要讲道理。设计模式是很好的实践，但不是圣经。不要把它粘在任何地方。
控制反转是当程序回调时得到的结果，例如gui程序。
例如，在旧学校菜单中，您可能有：
print "enter your name"
read name
print "enter your address"
read address
etc...
store in database
从而控制用户交互的流程。
在GUI程序或类似程序中，我们会说：
when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase
所以现在控制反转了。。。代替计算机以固定的顺序接受用户输入，用户控制输入数据的顺序以及数据保存在数据库中的时间。
基本上，任何带有事件循环、回调或执行触发器的东西都属于这一类。
在类中创建对象称为紧密耦合，Spring通过遵循设计模式（DI/IOC）来消除这种依赖性。在其中类的对象是传入构造函数而不是在类中创建的。此外，我们在构造函数中提供了超类引用变量，以定义更一般的结构。
我喜欢这样的解释：http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/
它开始很简单，还显示了代码示例。
消费者X需要被消费的类Y来完成某件事。这一切都很好，很自然，但X真的需要知道它使用Y吗？
如果X知道它使用的东西具有Y的行为、方法、财产等，而不知道谁真正实现了这些行为，这还不够吗？
通过提取X在Y中使用的行为的抽象定义（如下面的I所示），并让消费者X使用该行为的实例而不是Y，它可以继续做它所做的事情，而不必知道Y的细节。
在上图中，Y实现了I，X使用了I的一个实例。虽然很可能X仍然使用Y，但有趣的是X并不知道这一点。它只知道它使用了实现I的东西。
阅读文章了解更多信息和好处描述，如：
X不再依赖于Y更灵活，可以在运行时决定实现隔离代码单元，更容易测试
...
“IoC”这个首字母缩略词和它所代表的名字似乎最让人困惑的是，这个名字太迷人了——几乎是一个喧嚣的名字。
我们真的需要一个名字来描述过程式编程和事件驱动编程之间的区别吗？好吧，如果我们需要的话，但我们是否需要选择一个全新的“比生活更大”的名字，它让人困惑而不是解决问题？
