这是怎么一回事？反转（耦合）控制，更改方法签名的耦合方向。对于反向控制，方法签名的定义由方法实现（而不是方法的调用方）决定。此处完整解释

它解决了哪个问题？方法上的自顶向下耦合。这随后消除了重构的需要。

什么时候使用合适，什么时候不合适？对于定义良好的小型应用程序，如果没有太大的变化，可能会产生开销。然而，对于将要发展的定义较少的应用程序，它减少了方法签名的固有耦合。这使开发人员可以更自由地开发应用程序，避免了对代码进行昂贵的重构。基本上，允许应用程序在很少返工的情况下发展。

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

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

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

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

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

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

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

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

我在这里找到了一个非常清楚的例子，它解释了“控制是如何颠倒的”。

经典代码（无依赖注入）

以下是不使用DI的代码大致工作原理：

应用程序需要Foo（例如控制器），因此：应用程序创建Foo应用程序调用FooFoo需要Bar（例如服务），因此：Foo创建BarFoo调用BarBar需要Bim（服务、存储库…），因此：条形图创建Bim酒吧有点事

使用依赖注入

以下是使用DI的代码大致工作原理：

应用程序需要Foo，需要Bar，需要Bim，因此：应用程序创建Bim应用程序创建Bar并赋予它Bim应用程序创建Foo并给它Bar应用程序调用FooFoo调用Bar酒吧有点事

依赖项的控制是从一个被调用到另一个调用的。

它解决了什么问题？

依赖注入使得可以很容易地与注入类的不同实现进行交换。在单元测试时，您可以注入一个虚拟实现，这使测试更加容易。

例如：假设您的应用程序将用户上传的文件存储在Google Drive中，使用DI，您的控制器代码可能如下所示：

class SomeController
{
    private $storage;

    function __construct(StorageServiceInterface $storage)
    {
        $this->storage = $storage;
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

class GoogleDriveService implements StorageServiceInterface
{
    public function authenticate($user) {}
    public function putFile($file) {}
    public function getFile($file) {}
}

当你的需求发生变化时，比如说，你被要求使用Dropbox而不是GoogleDrive。您只需要为StorageServiceInterface编写一个dropbox实现。只要Dropbox实现符合StorageServiceInterface，就不必对控制器进行任何更改。

测试时，您可以使用虚拟实现为StorageServiceInterface创建模拟，其中所有方法都返回null（或根据测试要求的任何预定义值）。

相反，如果您有一个控制器类来构造具有如下新关键字的存储对象：

class SomeController
{
    private $storage;

    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

当您想要使用Dropbox实现进行更改时，必须替换构建新GoogleDriveService对象的所有行，并使用DropboxService。此外，在测试SomeController类时，构造函数总是期望GoogleDriveService类，并触发该类的实际方法。

什么时候合适，什么时候不合适？在我看来，当您认为类有（或可能有）替代实现时，您可以使用DI。

我同意NilObject，但我想补充一点：

如果你发现自己复制了一个完整的方法，只修改了一小段代码，你可以考虑用控制反转来处理它

如果你发现自己到处复制和粘贴代码，你几乎总是在做错事。编码为“一次且仅一次”的设计原则。

在类中创建对象称为紧密耦合，Spring通过遵循设计模式（DI/IOC）来消除这种依赖性。在其中类的对象是传入构造函数而不是在类中创建的。此外，我们在构造函数中提供了超类引用变量，以定义更一般的结构。

IoC原则有助于设计松散耦合的类，使其可测试、可维护和可扩展。