Какова реальная разница между "Bastard Injection" и "Poor Injection",

Из книги "Injection Injection in.Net" я знаю, что граф объекта должен быть создан в Корневой состав приложения, что имеет для меня большой смысл, когда вы используете IoC контейнер.

Во всех приложениях, которые я видел при попытке использовать DI, всегда есть два конструктора: один с зависимостями в качестве параметров и "по умолчанию" без параметров, который в свою очередь вызывает другой "новичка" по всем зависимостям, но в вышеупомянутой книге это называется "Bastard Injection anti-pattern", и это то, что я знал как "бедный человек инъекций".

Теперь, учитывая все это, я бы сказал тогда, что "Бедный Человек Инъекции" просто не будет использовать контейнер IoC и вместо этого будет кодировать весь графа объекта по указанному Корневому составу.

Итак, мои вопросы:

  • Я правильно понимаю эти понятия или я полностью отслежен?
  • Если вам все еще нужно регистрировать все зависимости в контейнере IoC против их кодирования вручную в точно таком же корневом составе, какова реальная выгода от использования контейнера IoC?
  • Если я неправильно понял, что такое "Бедный человек", может кто-то прояснить его?

Спасибо

ОТВЕТЫ

Ответ 1

Когда дело доходит до DI, существует много противоречивого использования терминологии. Термин Бедный Человек DI не является исключением. Для некоторых людей это означает одно, а другим - что-то другое.

Одна из вещей, которые я хотел сделать с этой книгой, заключалась в том, чтобы предоставить согласованный язык шаблонов для DI. Когда дело дошло до всех этих терминов с конфликтующим использованием, у меня было два варианта: придумать совершенно новый термин или выбрать наиболее распространенное использование (согласно моему субъективному мнению).

В общем, я предпочел повторно использовать существующую терминологию, а не составлять совершенно новый (и, следовательно, чужой) язык шаблонов. Это означает, что в некоторых случаях (например, "Бедный человек" ) у вас может быть другое понятие о том, что такое имя, чем определение, данное в книге. Это часто случается с книгами моделей.

По крайней мере, мне кажется, что это успокаивает то, что книга, похоже, выполнила свою работу, объясняя точно, как Бедный Человек DI, так и Bastard Injection, потому что интерпретация, данная в O.P., находится на месте.

Что касается реальной выгоды от контейнера DI, я отвечу на этот ответ: Аргументы против инверсии контейнеров управления

Ответ 2

Некоторые примечания к части 2) вопроса.

Если вам все равно нужно регистрировать все зависимости в контейнере IoC и их кодирование вручную в точно таком же корне, что и в реальной пользе от использования контейнера IoC?

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

  • У вас есть дерево зависимостей, или нет, при использовании контейнера IoC не будет набирать код. Представьте, что у вас есть 20 разных классов, которые зависят от того же IDependency. Если вы используете контейнер, вы можете предоставить конфигурацию, чтобы сообщить, какой экземпляр используется для IDependency. Вы сделаете это в одном месте, и контейнер позаботится о предоставлении экземпляра во всех зависимых классах

  • Контейнер также может управлять временем жизни объекта, что дает еще одно преимущество.

Все это, помимо других очевидных преимуществ, предоставляемых DI (тестируемость, ремонтопригодность, декодирование кода, расширяемость...)