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

所以我们开始。。。

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

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

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

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

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

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

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

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

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

这里可以找到非常简单的书面解释

http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html

上面写着-

“任何非平凡的应用程序都由两个或多个类组成相互协作以执行一些业务逻辑。传统上，每个对象都负责获得自己的对其协作对象（其依赖项）的引用。应用DI时，对象在创建时被赋予其依赖性某个外部实体在系统换句话说，依赖项被注入到对象中。"

在使用“控制反转”之前，你应该充分了解它的优点和缺点，如果你这样做，你应该知道为什么要使用它。

赞成的意见：

您的代码被解耦，因此您可以轻松地将接口的实现与其他实现交换它是针对接口而非实现进行编码的强大动力为代码编写单元测试是非常容易的，因为它只依赖于它在构造函数/setter中接受的对象，并且可以很容易地用正确的对象单独初始化它们。

欺骗：

IoC不仅会反转程序中的控制流，还会使其变得相当模糊。这意味着你不能再只读取代码并从一个地方跳到另一个地方，因为代码中通常存在的连接不再存在。相反，它在XML配置文件或注释中以及IoC容器的代码中解释这些元数据。出现了一类新的错误，即您的XML配置或注释错误，您可以花费大量时间来找出IoC容器在特定条件下向其中一个对象注入空引用的原因。

就我个人而言，我看到了IoC的优点，我非常喜欢它们，但我倾向于尽可能避免使用IoC，因为它将您的软件变成一个类的集合，这些类不再构成“真正的”程序，而只是需要通过XML配置或注释元数据组合在一起的东西，如果没有IoC，它就会崩溃。

对我来说，IoC/DI正在向调用对象推出依赖项。超级简单。

非技术性的答案是，在你打开引擎之前，你可以更换汽车的引擎。如果一切正常（界面），你就很好了。

控制反转是将控制权从库转移到客户端。当我们讨论将函数值（lambda表达式）注入（传递）到控制（改变）库函数行为的高阶函数（库函数）中的客户端时，它更有意义。

因此，这个模式的一个简单实现（具有巨大的含义）是一个更高阶的库函数（它接受另一个函数作为参数）。库函数通过赋予客户端提供“控制”函数作为参数的能力来传递对其行为的控制。

例如，“map”、“flatMap”等库函数是IoC实现。

当然，例如，有限的IoC版本是布尔函数参数。客户端可以通过切换布尔参数来控制库函数。

将库依赖项（承载行为）注入到库中的客户端或框架也可以被视为IoC

控制反转是一个通用原则，而依赖注入将这一原则实现为对象图构造的设计模式（即配置控制对象如何相互引用，而不是对象本身控制如何获取对另一个对象的引用）。

将控制反转视为一种设计模式，我们需要看看我们正在反转什么。依赖注入反转了对构建对象图的控制。如果用外行的术语来说，控制反转意味着程序中控制流的改变。例如，在传统的独立应用程序中，我们有一个主要的方法，从那里控制权被传递给其他第三方库（在这种情况下，我们使用了第三方的库的功能），但通过控制反转，控制权从第三方程序库代码转移到我们的代码，因为我们正在使用第三方代码库的服务。但在程序中还有其他方面需要反转，例如调用方法和线程来执行代码。

对于那些对控制反转感兴趣的人来说，已经发表了一篇论文，概述了控制反转作为一种设计模式的更完整的图景（OfficeFloor:使用办公模式来改进软件设计http://doi.acm.org/10.1145/2739011.2739013免费下载http://www.officefloor.net/about.html).

确定的关系如下：

控制反转（用于方法）=依赖（状态）注入+连续注入+线程注入

可用控制反转的上述关系汇总http://dzone.com/articles/inversion-of-coupling-control