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

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

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

确定的关系如下：

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

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

当你去杂货店，你妻子给你一份要买的产品清单时，就是控制权倒置。

在编程方面，她将回调函数getProductList（）传递给正在执行的函数-doShopping（）。

它允许函数的用户定义函数的某些部分，使其更加灵活。

什么是控制反转？

如果您遵循这两个简单的步骤，您就完成了控制反转：

把该做什么和什么时候该做分开。确保零件何时尽可能少地了解什么零件；反之亦然。

根据您用于实现的技术/语言，这些步骤中的每一个都有几种可能的技术。

--

控制反转（IoC）的反转部分令人困惑；因为反转是相对项。了解IoC的最好方法是忘记这个词！

--

示例

事件处理。事件处理程序（做什么部分）--引发事件（何时做部分）依赖注入。构造依赖项（做什么部分）的代码——在需要时为客户机实例化和注入依赖项，这通常由Dagger等DI工具来处理（什么时候做部分）。接口。组件客户端（何时执行部分）--组件接口实现（执行部分）x装置夹具。Setup和TearDown（要做的部分）--xUnit框架在开始时调用Setup，在结束时调用TearDown（何时做部分）模板方法设计模式。模板方法何时执行部分--基本子类实现何时执行部分COM.DllMain、DllCanUnload等中的DLL容器方法（做什么部分）--COM/OS（什么时候做部分）

维基百科文章。对我来说，控制反转就是将您按顺序编写的代码转换为委托结构。您的程序不是显式地控制一切，而是设置一个类或库，其中包含发生某些事情时要调用的某些函数。它解决了代码重复。例如，在过去，您可以手动编写自己的事件循环，在系统库中轮询新事件。现在，大多数现代API只需告诉系统库您感兴趣的事件，它会让您知道它们何时发生。控制反转是减少代码重复的一种实用方法，如果您发现自己复制了整个方法，只更改了一小段代码，可以考虑使用控制反转来解决它。在许多语言中，通过委托、接口甚至原始函数指针的概念，控制反转变得容易。它并不适合在所有情况下使用，因为这样编写时，程序的流程可能更难遵循。在编写可重用的库时，这是一种设计方法的有用方法，但除非它真的解决了代码重复问题，否则应该在自己程序的核心中谨慎使用。

IoC是关于颠倒代码和第三方代码（库/框架）之间的关系：

在正常的软件开发中，您编写main（）方法并调用“library”方法。您可以控制：）在IoC中，“框架”控制main（）并调用您的方法。该框架处于受控状态：(

DI（依赖注入）是关于控件在应用程序中如何流动的。传统的桌面应用程序具有从应用程序（main（）方法）到其他库方法调用的控制流，但DI控制流是反向的，框架负责启动应用程序、初始化应用程序并在需要时调用方法。

最终，你总会赢：）

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

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

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

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

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

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

我绝对喜欢IoC/DI。

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