IoC контейнеры, так ли они необходимы?

180

17 февраля 2019, 14:10

При использовании принципа "Инверсии зависимостей" рекомендуется использовать внедрение через конструктор, но в конечном итоге при увеличении сложности приложения увеличивается количество зависимостей, которые должны быть внедрены. Появляется огромный класс-Бог, который управляет всеми этими зависимостями (такой подход еще называют poor man's DI "Dependency Injection in .NET").

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

При использовании IoC контейнера фактически получается тот же самый подход, так зачем использовать тогда еще дополнительные настройки для контейнеров и лишние фреймворки?

При использовании IoC контейнера мы можем в любом месте запросить необходимый нам экземпляр (предварительно настроенный, конечно), (https://habr.com/post/131993/):

// там где нужно создать экземпляр ScheduleViewer мы вместо new, делаем так:
ScheduleViewer scheduleViewer= ninjectKernel.Get<ScheduleViewer>();

А не повышается ли тем самым связанность кода, когда мы везде вставим такие запросы на созданный экземпляр? Ведь тогда код становится практически не тестируемым (имеется ввиду модульное тестирование)

Answer 1

Вы совершенно правы в том, что использовать ninjectKernel.Get<ScheduleViewer>() вместо new ScheduleViewer() - не лучшая идея. Вот только DI не сводится к постоянным ninjectKernel.Get, это - анти-паттерн.

Вместо постоянных обращений к IoC-контейнеру, вам нужно запрашивать все ваши зависимости как параметры конструктора:

class Foo 
{
    private readonly ScheduleViewer viewer;
    public Foo(ScheduleViewer viewer)
    {
        this.viewer = viewer;
    }
}

Если же требуется создавать новые объекты - следует запросить их фабрику:

class Foo 
{
    private readonly Func<ScheduleViewer> viewerFactory;
    public Foo(Func<ScheduleViewer> viewerFactory)
    {
        this.viewerFactory = viewerFactory;
    }
}