IoC - 控制“反转”到哪里？ （它去哪儿了？）

Question

基础理论问题提醒！

关于 IoC。

我正在阅读有关 IoC 的文章，并意识到我对这个术语的确切含义并不完全满意。

然后，我遇到了一个关于 IoC 的特定答案，这让我意识到，IoC 不仅仅是关于类之间的控制/依赖关系，它是一个更笼统的术语：https://stackoverflow.com/a/3108/976537

“不是计算机按固定顺序接受用户输入，而是用户控制输入数据的顺序”

有趣。现在我对这个词感到更舒服了。

然后我正在阅读this article about IoC and achieving it via basic DI，我对此非常满意，一直在实施，知道等等的好处。

但是，在下面的场景中，从图 1 到图 2，我们从 OrderService 拿走了控制权。 OrderServices 现在只知道抽象，太好了。好处多多。

编辑：上图 1 中的代码（来自文章）是：

public class OrderService
{
    public void AcceptOrder(Order order)
    {
        new OrderDatabase().SaveOrder(order);
    }
}

那么，上面图2中实现IoC & DI后，代码为：

public class OrderService
{
    private IOrderSaver orderSaver;

    public OrderService(IOrderSaver orderSaver)
    {
        this.orderSaver = orderSaver;
    }

    public void AcceptOrder(Order order)
    {
        orderSaver.SaveOrder(order);
    }
}

我的问题是，控制权到哪里去了？

是否考虑将控制权转移到：

1 - 界面？ （我的感觉是这不太可能）

2 - 用于在运行时为 DI 连接的 IOC 容器？ （我的感觉是这个可能）

3 - 或 OrderDatabase（我觉得这是最有可能的答案）

SO - 控制权转移到了哪里？

Answer 1

参考以下代码

public class OrderService {
    public void AcceptOrder(Order order) {

        //...Domain logic such as validation

        //then save order
        new OrderDatabase().SaveOrder(order);
    }
}

OrderService 不应负责创建 OrderDatabase，这违反了单一职责原则 (SRP)。它与实现关注点紧密耦合，这违反了关注点分离 (SoC)。

通过反转OrderService 在创建依赖项时的控制， 它显式依赖于重构版本中所需功能的抽象

public class OrderService {
    private readonly IOrderSaver orderSaver;

    public OrderService(IOrderSaver orderSaver) {
        this.orderSaver = orderSaver;
    }

    public void AcceptOrder(Order order) {

        //...Domain logic such as validation

        //then save order
        orderSaver.SaveOrder(order);
    }
}

将创建依赖项的控制权委托/反转给OrderService 的使用者（负责创建和使用OrderService）

可以是 DI/IoC 容器或通过 pure DI（没有 DI 容器的依赖注入）

无论是通过容器的 DI 还是纯 DI 都无关紧要，因为它们将被视为与目标类无关的实现细节，在本例中为 OrderService。