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

所以我们开始。。。

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

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

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

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

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

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

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

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

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

例如，任务#1是创建对象。没有IOC概念，任务#1应该由程序员完成。但有了IOC概念后，任务#1将由容器完成。

简而言之，控件从编程器转换为容器。因此，它被称为控制反转。

我在这里找到了一个很好的例子。

假设你是一个物体。然后你去餐馆：

没有IoC：你要求“苹果”，当你要求更多时，你总是得到苹果。

与IoC：你可以要求“水果”。每次上桌你都可以得到不同的水果。例如，苹果、橙子或西瓜。

所以，很明显，当你喜欢品种时，IoC是首选。

控制反转是用于解耦系统中的组件和层的模式。该模式是通过在构建组件时将依赖项注入组件来实现的。这些依赖性通常作为接口提供，用于进一步去耦和支持可测试性。IoC/DI容器（如Castle Windsor、Unity）是可用于提供IoC的工具（库）。这些工具提供了超越简单依赖管理的扩展功能，包括生存期、AOP/Interception、策略等。a.减轻组件对管理其依赖性的责任。b.提供在不同环境中交换依赖实现的能力。c.允许通过模仿依赖关系来测试组件。d.提供在整个应用程序中共享资源的机制。a.进行测试驱动开发时至关重要。如果没有IoC，很难测试，因为被测组件与系统的其他部分高度耦合。b.开发模块化系统时至关重要。模块化系统是一种无需重新编译即可更换组件的系统。c.如果有许多跨领域的问题需要解决，尤其是在企业应用程序中，则至关重要。

控制反转意味着您控制组件（类）的行为。为什么称之为“反转”，因为在这种模式之前，类是硬连线的，并且确定了它们将要做什么。

导入具有TextEditor和SpellChecker类的库。现在，这个拼写检查器自然只检查英语的拼写。假设您希望TextEditor处理德语并能够进行拼写检查，那么您可以控制它。

在IoC的情况下，这种控制是反向的，即它是如何给你的？库将实现如下内容：

它将有一个TextEditor类，然后会有一个ISpellChecker（它是一个接口，而不是一个具体的SpellChecker类），当您在IoC容器中配置东西时，例如Spring，您可以提供自己的“ISpellChecker”实现，它将检查德语的拼写。因此，拼写检查将如何工作的控制权是从该库中获取并交给您的。这是IoC。

所以上面的数字1。什么是控制反转？维护是它为我解决的首要问题。它保证我使用的是接口，这样两个类就不会彼此亲密。

使用温莎城堡这样的容器，它可以更好地解决维护问题。能够在不更改一行代码的情况下，将一个连接到数据库的组件替换为一个使用基于文件的持久性的组件，这是非常棒的（配置更改完成了）。

一旦你进入泛型，它会变得更好。想象一下，拥有一个接收记录并发布消息的消息发布者。它不在乎它发布了什么，但它需要一个映射器将记录中的内容转换为消息。

public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

我写过一次，但现在如果我发布不同类型的消息，我可以向这组代码中注入许多类型。我还可以编写映射器，将相同类型的记录映射到不同的消息。将DI与Generics结合使用使我能够编写很少的代码来完成许多任务。

哦，是的，存在可测试性问题，但它们比IoC/DI的优势更为次要。

我绝对喜欢IoC/DI。

3.当你有一个中等规模的项目时，它会变得更加合适。我会说，当你开始感到疼痛时，它就变得合适了。