IoC - Control "Invert" 到哪里去了? (它去哪里?)

IoC - Where does Control "Invert" To? (Where does it go?)

基础理论题提醒!

关于 IoC。

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

然后,我遇到了一个关于 IoC 的具体答案,这让我意识到,IoC 不仅仅是关于 类 之间的 control/dependency,它是一个更笼统的术语:

"instead of the computer accepting user input in a fixed order, the user controls the order in which the data is entered"

有意思。现在我对这个词更熟悉了。

然后我正在阅读 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 - 控制权被倒置到哪里了?

参考以下代码

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);
    }
}

delegating/inverting 控制创建对 OrderService 消费者的依赖(负责创建和使用 OrderService)

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

无论是通过容器进行 DI 还是纯 DI 都不重要,因为它们将被视为与目标无关的实现细节 class,在本例中 OrderService