当第一次遇到控制反转（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，我们应该讨论依赖反转。
依赖反转：依赖于抽象，而不是具体。
控制反转：主与抽象，以及主如何成为系统的粘合剂。
我写了一些很好的例子，你可以在这里查看：
https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/
https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/
https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/
IoC是关于颠倒代码和第三方代码（库/框架）之间的关系：
在正常的软件开发中，您编写main（）方法并调用“library”方法。您可以控制：）在IoC中，“框架”控制main（）并调用您的方法。该框架处于受控状态：(
DI（依赖注入）是关于控件在应用程序中如何流动的。传统的桌面应用程序具有从应用程序（main（）方法）到其他库方法调用的控制流，但DI控制流是反向的，框架负责启动应用程序、初始化应用程序并在需要时调用方法。
最终，你总会赢：）
控制反转（IoC）模式是关于提供任何类型的回调，它“实现”和/或控制反应，而不是直接执行自己（换句话说，反转和/或将控制重定向到外部处理器/控制器）。依赖注入（DI）模式是IoC模式的一个更具体的版本，它完全是从代码中删除依赖项。
每个DI实现都可以被视为IoC，但不应该称之为IoC。因为实现依赖注入比回调更困难（不要使用通用术语“IoC”来降低产品的价值）。
例如DI，假设您的应用程序有一个文本编辑器组件，并且您希望提供拼写检查。你的标准代码应该是这样的：
public class TextEditor {
private SpellChecker checker;
public TextEditor() {
this.checker = new SpellChecker();
}
}
我们在这里所做的工作在TextEditor和SpellChecker之间创建了依赖关系。在IoC场景中，我们会这样做：
public class TextEditor {
private IocSpellChecker checker;
public TextEditor(IocSpellChecker checker) {
this.checker = checker;
}
}
在第一个代码示例中，我们正在实例化SpellChecker（this.checker=new SpellCheckr（）；），这意味着TextEditor类直接依赖于SpellChecker类。
在第二个代码示例中，我们通过在TextEditor的构造函数签名中使用SpellChecker依赖类（而不是在类中初始化依赖项）来创建抽象。这允许我们调用依赖项，然后将其传递给TextEditor类，如下所示：
SpellChecker sc = new SpellChecker(); // dependency
TextEditor textEditor = new TextEditor(sc);
现在，创建TextEditor类的客户端可以控制使用哪个SpellChecker实现，因为我们正在将依赖项注入TextEditor签名中。
注意，就像IoC是许多其他模式的基础一样，上面的示例只是依赖注入类型中的一种，例如：
构造函数注入。IocSpellChecker的实例将自动传递给构造函数，或手动传递给构造函数。沉淀剂注入。IocSpellChecker的实例将通过setter方法或公共属性传递。服务查找和/或服务定位器其中TextEditor将向已知的提供者请求IocSpellChecker类型的全局使用的实例（服务）（这可能不存储所述实例，而是一次又一次地询问提供者）。
“IoC”这个首字母缩略词和它所代表的名字似乎最让人困惑的是，这个名字太迷人了——几乎是一个喧嚣的名字。
我们真的需要一个名字来描述过程式编程和事件驱动编程之间的区别吗？好吧，如果我们需要的话，但我们是否需要选择一个全新的“比生活更大”的名字，它让人困惑而不是解决问题？
为了理解这个概念，控制反转（IoC）或依赖反转原理（DIP）涉及两个活动：抽象和反转。依赖注入（DI）只是为数不多的反转方法之一。
要了解更多信息，您可以在此处阅读我的博客
这是怎么一回事？
这是一种让实际行为来自边界之外的实践（面向对象编程中的类）。边界实体只知道它的抽象（例如面向对象编程中的接口、抽象类、委托）。
它解决了什么问题？
在编程方面，IoC试图通过使单片代码模块化、解耦其各个部分并使其可单元测试来解决单片代码。
什么时候合适，什么时候不合适？
这在大多数情况下都是合适的，除非您有只需要单片代码的情况（例如非常简单的程序）
