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而言）则无关。