Почему платформы внедрения зависимостей поддерживают иерархии контейнеров?

Question

Я следил за серией Дэниела Каззулино о создании контейнера DI с использованием TDD В пятой части серии он добавляет поддержку контейнерных иерархий, не комментируя, что делает эту функцию полезной. Я видел упоминание о поддержке иерархий во многих структурах DI, но мне трудно понять, когда они будут использоваться и почему. Может кто-нибудь предложить какое-то понимание?

Answer 1

Вот пример , который использует дочерние контейнеры в сценарии, аналогичном описанному Мэттом. Он использует дочерние контейнеры для выбора между различными конфигурациями базы данных.

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

Answer 2

Я оставил комментарий в блоге kzu, задав тот же вопрос. Жаль, что он не прояснил сценарий использования такой функции до ее кодирования.

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

Это может быть далеко от базы, но это лучшее, что я мог придумать.

Answer 3

Лучший пример, который я знаю для вложенных контейнеров, - это система управления окнами. Очень просто разделить задачи, чтобы каждая вкладка / окно имело свой собственный контейнер, независимый от других вкладок / окон, причем все контейнеры окон наследуют глобальные зависимости от родительского контейнера.

Это особенно необходимо, если у вас могут быть дубликаты вкладок / окон, поскольку во многих случаях вы хотите различать экземпляры различных классов для каждой дублирующейся вкладки / окна

Answer 4

Есть веская причина иметь дочерние контейнеры, если внедрение зависимостей полностью охватывается проектом. Давайте представим приложение, которое обрабатывает сообщения от двух разных, но похожих систем. Большая часть обработки аналогична, но есть различия в поддержке совместимости от этих систем. Наша цель - повторно использовать код, который мы можем, при написании другого кода в зависимости от требований.

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

У нас есть контейнер верхнего уровня, в котором есть элементы, которые не различаются между двумя системами. Затем у нас есть дочерние контейнеры, которые do различаются в разных системах. Когда приходит сообщение, мы запрашиваем у дочернего DI-контейнера messageProcessor. На основе конфигурации этого контейнера (при необходимости возвращаясь к родительскому контейнеру) платформа DI может возвращать messageProcessor (являющийся объектом, поддерживаемым соответствующими сотрудниками) для рассматриваемой системы.

Пожалуйста, оставьте комментарий, если это не четкий ответ. Кроме того, вы можете искать «проблема ног робота». Каждая нога идентична, но одной нужна левая нога, а другой нужна правая нога. Мы могли бы иметь дочерний контейнер DI для каждой ноги.