当第一次遇到控制反转（IoC）时，它可能非常令人困惑。
这是怎么一回事？它解决了哪个问题？什么时候使用合适，什么时候不合适？
当前回答
只回答第一部分。这是怎么一回事？
控制反转（IoC）意味着先创建依赖项的实例，然后创建类的后一个实例（可选地通过构造函数注入它们），而不是先创建类的实例，再由类实例创建依赖项实例。因此，控制反转反转程序的控制流程。调用者控制程序的控制流，而不是被调用者控制控制流（同时创建依赖项）。
其他回答
我觉得用这么多先前的答案回答这个问题有点尴尬，但我只是觉得任何答案都没有足够简单地说明这个概念。
所以我们开始。。。
在非IOC应用程序中，您需要对流程进行编码，并在其中包含所有详细步骤。考虑一个创建报告的程序，它将包含设置打印机连接、打印页眉、遍历详细记录、打印页脚、可能执行页面馈送等的代码。
在IOC版本的报告程序中，您将配置一个通用的、可重用的报告类的实例，即一个包含打印报告的过程流但其中没有任何详细信息的类。您提供的配置可能使用DI来指定报告应该调用哪个类来打印标题、报告应该调用什么类来打印详细信息行、，以及Report应该调用什么类来打印页脚。
因此，控制反转来自控制过程，而不是代码，而是包含在一个外部的、可重用的类（Report）中，该类允许您指定或注入（通过DI）报告的详细信息-页眉、详细信息行和页脚。
通过提供不同的细节类集，可以使用同一Report类（控制类）生成任意数量的不同报告。您通过依赖Report类来提供控件，而只是通过注入来指定报表之间的差异，从而实现了控件的反转。
在某些方面，IOC可以与驱动器备份应用程序相比较-备份总是执行相同的步骤，但备份的文件集可能完全不同。
现在具体地回答最初的问题。。。
这是怎么一回事？IOC依赖于一个可重用的控制器类，并提供针对当前问题的详细信息。它解决了哪个问题？防止您必须重述控制流程。什么时候使用合适，什么时候不合适？无论何时创建控制流始终相同且仅更改细节的流程流。在创建一次性自定义流程时，您不会使用它。
最后，IOC不是DI，DI也不是IOC——DI通常可以在IOC中使用（为了说明抽象控制类的细节）。
无论如何，我希望这有帮助。
例如，任务#1是创建对象。没有IOC概念，任务#1应该由程序员完成。但有了IOC概念后，任务#1将由容器完成。
简而言之，控件从编程器转换为容器。因此，它被称为控制反转。
我在这里找到了一个很好的例子。
对我来说，IoC/DI正在向调用对象推出依赖项。超级简单。
非技术性的答案是，在你打开引擎之前，你可以更换汽车的引擎。如果一切正常（界面），你就很好了。
使用IoC，您不会对对象进行更新。您的IoC容器将做到这一点，并管理它们的生命周期。
它解决了必须手动将一种类型对象的每个实例化更改为另一种类型的问题。
如果您的功能将来可能会发生变化，或者根据中使用的环境或配置而有所不同，则使用此选项是合适的。
这里可以找到非常简单的书面解释
http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html
上面写着-
“任何非平凡的应用程序都由两个或多个类组成相互协作以执行一些业务逻辑。传统上，每个对象都负责获得自己的对其协作对象（其依赖项）的引用。应用DI时，对象在创建时被赋予其依赖性某个外部实体在系统换句话说，依赖项被注入到对象中。"
