Правильное использование контейнера для инъекций зависимости
Так что внедрение зависимости тогда. Я понимаю концепции (я думаю!) И использование контейнеров. То, что я не понимаю, — лучший способ сделать ваш DI-контейнер доступным везде.
Если у вас есть класс DB, вы вводите контейнер в конструктор? Чтобы вы могли вызывать методы контейнера DI для создания зависимых объектов?
Вы делаете то же самое для своего класса конфигурации, своего почтового класса, своего класса регистратора и так далее? Как сделать свой DI-контейнер доступным везде?
Помощь оценена!
Решение
Аналогично тому, что сказал CJD, если ваш DIC доступен везде, тогда это было бы больше похоже на Глобальный реестр
В случае класса DB, если его зависимости передаются через тип, указывающий на параметры, определяющие их внешне, в документации или любым другим приемлемым способом, тогда DIC может внедрить эти зависимости.
Полезные ресурсы:
Энтони Ферра / ircmaxell
видео о внедрении зависимостей
Фабиан Потенциер
статья о том, нужен ли вам DIC
Роб Аллен
видео Введение зависимости зависимости
Стефан Хохдорфер
видео 7 смертельных грехов инъекций зависимости
Мартин Фаулер:
Переполнение стека:
Другие решения
Я понимаю, что ты не сделать его доступным везде. Вы регистрируете все объекты и их зависимости, а затем при создании объекта контейнер IoC предоставляет все свои зависимости (и зависимости 2-го, 3-го, n-го уровня).
Так что foo нужен bar, bar нужен baz и qux, а qux нужен quux. Foo требуется вводить только bar, IoC позаботится о деталях предоставления bar с его зависимостями и так далее.
Если foo потребуется сделать больше баров позже, это зависит от фабрики баров, которую также может предоставить IoC.