我觉得用这么多先前的答案回答这个问题有点尴尬，但我只是觉得任何答案都没有足够简单地说明这个概念。

所以我们开始。。。

在非IOC应用程序中，您需要对流程进行编码，并在其中包含所有详细步骤。考虑一个创建报告的程序，它将包含设置打印机连接、打印页眉、遍历详细记录、打印页脚、可能执行页面馈送等的代码。

在IOC版本的报告程序中，您将配置一个通用的、可重用的报告类的实例，即一个包含打印报告的过程流但其中没有任何详细信息的类。您提供的配置可能使用DI来指定报告应该调用哪个类来打印标题、报告应该调用什么类来打印详细信息行、，以及Report应该调用什么类来打印页脚。

因此，控制反转来自控制过程，而不是代码，而是包含在一个外部的、可重用的类（Report）中，该类允许您指定或注入（通过DI）报告的详细信息-页眉、详细信息行和页脚。

通过提供不同的细节类集，可以使用同一Report类（控制类）生成任意数量的不同报告。您通过依赖Report类来提供控件，而只是通过注入来指定报表之间的差异，从而实现了控件的反转。

在某些方面，IOC可以与驱动器备份应用程序相比较-备份总是执行相同的步骤，但备份的文件集可能完全不同。

现在具体地回答最初的问题。。。

这是怎么一回事？IOC依赖于一个可重用的控制器类，并提供针对当前问题的详细信息。它解决了哪个问题？防止您必须重述控制流程。什么时候使用合适，什么时候不合适？无论何时创建控制流始终相同且仅更改细节的流程流。在创建一次性自定义流程时，您不会使用它。

最后，IOC不是DI，DI也不是IOC——DI通常可以在IOC中使用（为了说明抽象控制类的细节）。

无论如何，我希望这有帮助。

由于这个问题已经有很多答案，但没有一个显示反转控制项的分解，我认为有机会给出一个更简洁和有用的答案。

控制反转是一种实现依赖反转原理（DIP）的模式。DIP声明如下：1。高级模块不应依赖于低级模块。两者都应该依赖于抽象（例如接口）。2.摘要不应依赖于细节。细节（具体实现）应该依赖于抽象。

控制反转有三种类型：

界面反转提供程序不应定义接口。相反，使用者应该定义接口，提供者必须实现它。接口反转允许消除每次添加新提供者时修改使用者的必要性。

流量反演更改流量控制。例如，您有一个控制台应用程序，要求输入许多参数，在输入每个参数后，您必须按enter键。您可以在此处应用Flow Inversion，并实现桌面应用程序，用户可以选择输入参数的顺序，用户可以编辑参数，在最后一步，用户只需按Enter键一次。

创建反转它可以通过以下模式实现：工厂模式、服务定位器和依赖注入。创建反转有助于消除类型之间的依赖关系，将依赖关系对象创建过程移到使用这些依赖关系对象的类型之外。为什么依赖关系不好？这里有几个例子：在代码中直接创建一个新对象会使测试更加困难；不重新编译就不可能更改程序集中的引用（违反OCP原则）；你不能轻易地用web UI替换桌面UI。

我同意NilObject，但我想补充一点：

如果你发现自己复制了一个完整的方法，只修改了一小段代码，你可以考虑用控制反转来处理它

如果你发现自己到处复制和粘贴代码，你几乎总是在做错事。编码为“一次且仅一次”的设计原则。

控制反转，（或IoC），是关于获得自由（你结婚了，失去了自由，你被控制了。你离婚了，你刚刚实现了控制反转。这就是我们所说的“脱钩”。好的计算机系统阻碍了一些非常亲密的关系。)更灵活（你办公室的厨房只供应干净的自来水，这是你想喝水时的唯一选择。你的老板通过安装一台新的咖啡机实现了控制反转。现在你可以灵活选择自来水或咖啡。)和更少的依赖性（你的伴侣有工作，你没有工作，你在经济上依赖你的伴侣，所以你受到控制。你找到了工作，你实现了控制反转。良好的计算机系统鼓励依赖。）

当你使用台式电脑时，你已经从（或者说，被控制）了。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个写得不好的软件会让你更加痛苦。如果你把桌面换成笔记本电脑，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是由电脑控制。

通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。

考虑到上述想法。我们仍然错过了IoC的一个关键部分。在IoC的场景中，软件/对象使用者是一个复杂的框架。这意味着您创建的代码不是自己调用的。现在让我们来解释一下为什么这种方式对web应用程序更有效。

假设您的代码是一组工作人员。他们需要造一辆车。这些工人需要一个地方和工具（软件框架）来制造汽车。一个传统的软件框架就像一个有很多工具的车库。因此，工人们需要自己制定计划，并使用工具来制造汽车。造一辆车不是一件容易的事，工人们很难做好计划并进行适当的合作。一个现代化的软件框架将像一个拥有所有设施和管理人员的现代化汽车工厂。工人不必制定任何计划，管理者（框架的一部分，他们是最聪明的人，制定了最复杂的计划）将帮助协调，以便工人知道何时完成他们的工作（框架调用您的代码）。工人们只需要足够灵活地使用经理给他们的任何工具（通过使用依赖注入）。

尽管工人将项目管理的控制权交给了管理者（框架）。但有一些专业人士帮助是很好的。这就是IoC的真正来源。

具有MVC架构的现代Web应用程序依赖于框架来执行URL路由，并将控制器放置在适当的位置以供框架调用。

依赖注入和控制反转是相关的。依赖注入在微观层面，控制反转在宏观层面。为了完成一顿饭（实现IoC），你必须吃每一口（实现DI）。

在类中创建对象称为紧密耦合，Spring通过遵循设计模式（DI/IOC）来消除这种依赖性。在其中类的对象是传入构造函数而不是在类中创建的。此外，我们在构造函数中提供了超类引用变量，以定义更一般的结构。

“IoC”这个首字母缩略词和它所代表的名字似乎最让人困惑的是，这个名字太迷人了——几乎是一个喧嚣的名字。

我们真的需要一个名字来描述过程式编程和事件驱动编程之间的区别吗？好吧，如果我们需要的话，但我们是否需要选择一个全新的“比生活更大”的名字，它让人困惑而不是解决问题？