Не вините структуру внедрения зависимостей

За последние пару месяцев я слышал и читал довольно много заявлений о том, что системы внедрения зависимостей — это плохие вещи, которых вы должны избегать, как чумы. На мой взгляд, это просто результат отказа от чего-либо, потому что он слишком долго использовался. Не поймите меня неправильно, я использую их годами и полностью осознаю последствия неправильного использования этих фреймворков и их влияние на вашу кодовую базу. Однако я также узнал, что каждый инструмент имеет свои преимущества и недостатки. Знание его сильных и слабых сторон является частью работы профессионального разработчика программного обеспечения. Увольнение инструмента из-за последнего мне кажется немного невежественным. Итак, давайте поговорим о том, откуда это идет.

Почему люди используют их?

Рассмотрим (надуманную) схему ниже.

В таком дизайне я могу придумать несколько причин, по которым разработчики решают использовать инфраструктуру внедрения зависимостей. С одной стороны, они могут поощрять разработчиков, разрабатывающих свои классы таким образом, что они зависят только от абстракций (1). На мой взгляд, это хорошая вещь, поскольку зависимость от более стабильных вещей   помогает предотвратить эффект пульсации. А поскольку абстракция более стабильна, чем реализация, мы хороши. Приятным побочным эффектом всего этого является то, что он позволяет вам переключать одну реализацию с другой (2), также известной как  шаблон стратегии, Это работает особенно хорошо, если вам нужно, чтобы ваши модульные тесты работали против реализации этой абстракции, удобной для тестирования (4). И не забудьте систему, которая любит динамически загружать реализации (или плагины) из внешних модулей (6).

В большинстве реальных проектов разные реализации разных абстракций регулируются разными жизненными циклами (3). Вот где может появиться структура внедрения зависимостей. Они дают вам большой контроль над тем, когда следует создавать реализацию абстракции, при каких обстоятельствах ее можно использовать повторно, и что-то, что часто упускается, когда распоряжаться экземпляром.  Autofac  — один из тех примеров, который делает это действительно хорошо. Он рассматривает одноразовые товары как IDisposable первостепенную задачу и предполагает, что любой реализуемый объект  должен быть удален, когда (вложенный) контейнер выходит из области видимости.

Поскольку контейнер уже отвечает за подключение реализаций к абстракциям, он также может внедрять объекты, которые имеют дело с сквозными проблемами (5). Примером этого является  декоратор,  который тайно отслеживает вызовы между объектами и регистрирует предупреждающие сообщения, если превышены определенные пороговые значения. Но я также видел такие примеры, как сбор телеметрии, экранирование исключений и динамический выбор стратегий на основе среды хостинга.

Тогда почему некоторые люди так презирают их?

Примеры, которые я только что привел, являются действительными и полезными решениями для реальных проблем. Так почему же некоторые разработчики думают, что структуры внедрения зависимостей — такая плохая вещь? Ну, так же, как и Test Driven Development, которая может действительно повредить вам, если вы не сделаете это  правильнонеправильное использование структуры DI может причинить боль. Что-то, что я часто слышал на протяжении многих лет, — это магия, которую внедряет такая структура, в частности, в течение жизненного цикла экземпляров, предоставляемых этой структурой. И если вам нужно знать, каков настроенный жизненный цикл, поиск оригинальной регистрации может быть утомительным. Если у вас всего пара регистраций, вам, вероятно, повезло. Но большинство монолитов, которые я видел, содержат сотни таких регистраций, что приводит к громоздкому загрузочному коду. Особенно, если типы регистрируются динамически или при представлении типа через все его открытые интерфейсы, может оказаться практически невозможным найти правильную регистрацию.

Еще одна проблема, которую я слышал (и наблюдал из первых рук) — это глубоко вложенные стеки вызовов, включаемые, когда не удается разрешить какую-либо зависимость. Autofac делает это вполне нормально, но я видел несколько довольно запутанных дампов стека с другими фреймворками. Вы можете заметить, что я продолжаю использовать термин  каркас,  а не  библиотека . Это потому, что большинство этих библиотек не ведут себя как библиотеки. Другими словами, если вы не будете осторожны, их пресловутые щупальца, как правило, заражают всю вашу кодовую базу. И я уже упоминал эту тенденцию вводить  Iwhatever интерфейсы для всего, что используется в качестве зависимости. Не то, что мне нравится видеть в моей базе кода, учитывая, что мы стараемся следовать проверенным методам, таким как  ролевые интерфейсы  и Принцип разделения интерфейса . Не говоря уже о чрезмерной фальсификации в ваших  юнит-тестах,  которая обычно является результатом этого

Как правильно понимать терминологию

Прежде чем мы поговорим о том, как правильно сделать внедрение зависимостей, я думаю, что мне нужно сначала уточнить некоторую терминологию, начиная с  Inversion of Control  (IoC). Это процесс перемещения ответственности за создание зависимости вне класса в зависимости от нее. Другими словами, вместо того, чтобы иметь  Order Processing модуль (из рисунка вверху этого поста)  new— конкретную реализацию  IOrderRepository, мы делегируем это коду, который создает и / или потребляет  Order Processing модуль. Вам не нужна DI-инфраструктура для этого. Но поскольку это основная работа инфраструктуры DI, вполне логично, что очень многие люди называют их  контейнерами IoC . В некотором смысле, контейнер становится ответственным за  инъекцию правильная зависимость от модуля обработки заказов (такого как конструктор), следовательно, смешанное использование этих терминов.

Тем не менее, многие люди все еще думают, что «D» в SOLID также означает  внедрение зависимости  . Тем не менее, «D» обозначает  принцип инверсии зависимости  (или DIP для краткости), который ортогональн к концепциям, которые я только что объяснил. DIP говорит об изменении зависимости между объектами таким образом, чтобы абстракции более высокого уровня не зависели от абстракций более низкого уровня. За этим стоит идея, что низкоуровневые абстракции имеют тенденцию быть более общими и многократно используемыми, и поэтому они более подвержены изменениям. Это также является одним из принципов  успешного управления пакетами  (которое также вдохновлено SOLID). В качестве примера рассмотрим различия между левой и правой сторонами изображения:

Хотя они кажутся похожими, есть небольшая разница. Левая сторона определяет довольно общий  IStoreOrders<T> интерфейс, который принадлежит тому, что, вероятно, находится на уровне данных. Основываясь на названии, я предполагаю, что он будет определять методы общего назначения для создания, удаления и запроса заказов. Обратите внимание, что зависимость передается от модуля обработки заказов, абстракции более высокого уровня, к  IStoreOrders интерфейсу, абстракции более низкого уровня. Это также означает, что реализация этого интерфейса не может делать какие-либо предположения о том, что пытается выполнить вызывающая сторона. Конечно, вы можете добавить больше функциональных методов к этому интерфейсу (например, как показано на правой стороне), но это, вероятно, означает, что у абстракции будет огромное количество методов.

DIP устраняет эту зависимость, позволяя модулю Order Order определить, что ему нужно для функционирования, и позволяя низкоуровневому уровню реализовать их. Это отделяет модуль от любых низкоуровневых деталей, которые будут часто меняться. Это также хорошо согласуется с   мышлением чистой архитектуры . Приятным побочным эффектом этого является то, что он помогает избежать тех ужасных интерфейсов, которые являются не чем иным, как именем реализации класса с префиксом  I.

Правильно делать инъекции зависимостей

Теперь, когда у нас есть разработанная терминология, и прежде чем прийти к какому-либо заключению, позвольте мне сначала поделиться некоторыми рекомендациями о том, как сделать внедрение зависимостей таким образом, чтобы вам не было больно. Например, статическое изменяемое состояние (все, что является  staticили ведет себя так) всегда плохо. Это вызывает странные проблемы в многопоточных средах, особенно теперь мы все обнявшись  async и  await. Зная это, я убиваюсь, когда вижу, что Microsoft так активно продвигает   шаблон Service Locator . Предполагается, что вы можете разрешить зависимость с помощью следующего оператора:

ServiceLocator.Current.GetInstance<IStoreOrders>();

Но это статический объект. Использование этого в производстве, где все потоки будут повторно использовать те же самые зависимости, в основном хорошо. Но просто попробуйте переключить ваш тестовый фреймворк с MSTest на  Xunit,  где модульные тесты выполняются параллельно и каждый из них должен иметь свой собственный (поддельный) экземпляр зависимости. Так  что не используйте сервисные локаторы .

Уничтожив этот шаблон, следует убедиться, что вы используете только контейнер в корне графа зависимостей. Другими словами,   разрешите  только корневой объект из контейнера  и  никогда  не устанавливайте прямую  зависимость от этого контейнера . Позвольте контейнеру обрабатывать любые зависимости, которые имеют объекты в графе. Это помогает вам рассматривать контейнер как библиотеку, а не как фреймворк, который заканчивается везде в вашей кодовой базе.

interface IDiscountPolicy
{
    float GetDiscount(float originalPrice);
    bool AllowsCombiningWithOtherDiscounts { get; }
}

internal class OrderManagementModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder.RegisterType<SmallOrderDiscountPolicy>().Keyed<IDiscountPolicy>(OrderType.Small);
        builder.RegisterType<LargeOrderDiscountPolicy>().Keyed<IDiscountPolicy>(OrderType.Large);

        builder.Register<GetDiscountPolicy>(ctx =>
        {
            var container = ctx.Resolve<IComponentContext>();

            return orderType => container.ResolveKeyed<IDiscountPolicy>(orderType);
        });
    }
}

var builder = new ContainerBuilder();
builder.RegisterModule<OrderManagementModule>();

IContainer container = builder.Build();