控制反转是关于分离关注点。

没有IoC：你有一台笔记本电脑，你不小心弄坏了屏幕。糟糕的是，你发现市场上没有同一型号的笔记本电脑屏幕。所以你被卡住了。

IoC：你有一台台式电脑，你不小心把屏幕弄坏了。你发现你可以从市场上买到几乎所有的桌面显示器，而且它与你的桌面很好地配合。

在这种情况下，您的桌面成功地实现了IoC。它接受各种类型的显示器，而笔记本电脑不接受，它需要一个特定的屏幕来固定。

控制反转，（或IoC），是关于获得自由（你结婚了，失去了自由，你被控制了。你离婚了，你刚刚实现了控制反转。这就是我们所说的“脱钩”。好的计算机系统阻碍了一些非常亲密的关系。)更灵活（你办公室的厨房只供应干净的自来水，这是你想喝水时的唯一选择。你的老板通过安装一台新的咖啡机实现了控制反转。现在你可以灵活选择自来水或咖啡。)和更少的依赖性（你的伴侣有工作，你没有工作，你在经济上依赖你的伴侣，所以你受到控制。你找到了工作，你实现了控制反转。良好的计算机系统鼓励依赖。）

当你使用台式电脑时，你已经从（或者说，被控制）了。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个写得不好的软件会让你更加痛苦。如果你把桌面换成笔记本电脑，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是由电脑控制。

通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。

考虑到上述想法。我们仍然错过了IoC的一个关键部分。在IoC的场景中，软件/对象使用者是一个复杂的框架。这意味着您创建的代码不是自己调用的。现在让我们来解释一下为什么这种方式对web应用程序更有效。

假设您的代码是一组工作人员。他们需要造一辆车。这些工人需要一个地方和工具（软件框架）来制造汽车。一个传统的软件框架就像一个有很多工具的车库。因此，工人们需要自己制定计划，并使用工具来制造汽车。造一辆车不是一件容易的事，工人们很难做好计划并进行适当的合作。一个现代化的软件框架将像一个拥有所有设施和管理人员的现代化汽车工厂。工人不必制定任何计划，管理者（框架的一部分，他们是最聪明的人，制定了最复杂的计划）将帮助协调，以便工人知道何时完成他们的工作（框架调用您的代码）。工人们只需要足够灵活地使用经理给他们的任何工具（通过使用依赖注入）。

尽管工人将项目管理的控制权交给了管理者（框架）。但有一些专业人士帮助是很好的。这就是IoC的真正来源。

具有MVC架构的现代Web应用程序依赖于框架来执行URL路由，并将控制器放置在适当的位置以供框架调用。

依赖注入和控制反转是相关的。依赖注入在微观层面，控制反转在宏观层面。为了完成一顿饭（实现IoC），你必须吃每一口（实现DI）。

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

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

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

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

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

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

我绝对喜欢IoC/DI。

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

为了理解这个概念，控制反转（IoC）或依赖反转原理（DIP）涉及两个活动：抽象和反转。依赖注入（DI）只是为数不多的反转方法之一。

要了解更多信息，您可以在此处阅读我的博客

这是怎么一回事？

这是一种让实际行为来自边界之外的实践（面向对象编程中的类）。边界实体只知道它的抽象（例如面向对象编程中的接口、抽象类、委托）。

它解决了什么问题？

在编程方面，IoC试图通过使单片代码模块化、解耦其各个部分并使其可单元测试来解决单片代码。

什么时候合适，什么时候不合适？

这在大多数情况下都是合适的，除非您有只需要单片代码的情况（例如非常简单的程序）

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

控制权倒置是项目责任转移的一个指标。

当依赖项被授予直接作用于调用者空间的能力时，每次都会发生控制反转。

最小的IoC是通过引用传递变量，让我们先看看非IoC代码：

function isVarHello($var) {
    return ($var === "Hello");
}

// Responsibility is within the caller
$word = "Hello";
if (isVarHello($word)) {
    $word = "World";
}

现在，让我们通过将结果的责任从调用者转移到依赖项来反转控制：

function changeHelloToWorld(&$var) {
    // Responsibility has been shifted to the dependency
    if ($var === "Hello") {
        $var = "World";
    }
}

$word = "Hello";
changeHelloToWorld($word);

下面是另一个使用OOP的示例：

<?php

class Human {
    private $hp = 0.5;

    function consume(Eatable $chunk) {
        // $this->chew($chunk);
        $chunk->unfoldEffectOn($this);
    }

    function incrementHealth() {
        $this->hp++;
    }
    function isHealthy() {}
    function getHungry() {}
    // ...
}

interface Eatable {
    public function unfoldEffectOn($body);
}

class Medicine implements Eatable {
    function unfoldEffectOn($human) {
        // The dependency is now in charge of the human.
        $human->incrementHealth();
        $this->depleted = true;
    }
}

$human = new Human();
$medicine = new Medicine();
if (!$human->isHealthy()) {
    $human->consume($medicine);   
}

var_dump($medicine);
var_dump($human);

*)免责声明：现实世界中的人类使用消息队列。