IoC - Куда относится контроль «Инвертировать»?(Куда это идет?) - PullRequest
Новая
       58

IoC - Куда относится контроль «Инвертировать»?(Куда это идет?)

2 голосов
/ 20 сентября 2019

Оповещение о базовых теоретических вопросах!

Речь идет о IoC.

Я читал об IoC и понял, что мне не совсем понятно точное значение этого термина.

Затем я наткнулся на конкретный Ответ об IoC, который заставил меня осознать, что IoC - это не просто контроль / зависимость между классами, это гораздо более общий термин: https://stackoverflow.com/a/3108/976537

«вместо того, чтобы компьютер принимал ввод пользователя в фиксированном порядке, пользователь контролирует порядок ввода данных»

Интересно.Теперь мне гораздо удобнее использовать этот термин.

Тогда я читал эту статью о IoC и достигал ее с помощью базового DI , который мне очень удобен, все время внедряю,знать преимущества и т. д.

Но в приведенном ниже сценарии, переходя от рисунка 1 к рисунку 2, мы забираем контроль у OrderService.OrderServices теперь знает об абстракции, отлично.Много преимуществ.enter image description here

РЕДАКТИРОВАТЬ: код (из статьи) на рисунке 1, выше, является: 

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

Затем, после того как IoC & DI реализован вРисунок 2 выше, код: 

public class OrderService
{
    private IOrderSaver orderSaver;

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

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

Мой вопрос: куда считается, что контроль ушел?

Считается ли управление перенесенным на:

1 - интерфейс?(я чувствую, что это маловероятно)

2 - Контейнер IOC, используемый для подключения к DI во время выполнения?(я чувствую, что это возможно)

3 - или OrderDatabase (я чувствую, что это наиболее вероятный ответ)

SO - где управление было инвертировано?

1 Ответ

1 голос
/ 20 сентября 2019

Ссылаясь на следующий код 

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 или через чистый DI ( Внедрение зависимостей без контейнера DI )

Независимо от того, используется ли DI через контейнер или чистый DIнезависимо от того, как они будут считаться деталями реализации, которые не имеют отношения к целевому классу, в этом случае OrderService.

...