Comments 7
Сергей Парамонов! Вот дела! Я ж тебя знаю! Слушаю слушаю подкаст и даже не подозреваю, что с одним из авторов лично знаком! Приятно!
Любопытно про IoC, добавлю свои 5 копеек.
1. Контейнер — такой же сервис (используемый для получения сервисов). Поэтому его можно положить в контейнер, т.е. в себя же. Чем это хорошо? Ссылку на контейнер можно объявить dependency-свойством и тогда обращение к контейнеру не придётся делать через singleton, класс получит контейнер, как любой другой сервис.
2. DI-контейнер, который используется у нас (Microsoft Unity), позволяет строить дерево контейнеров. Child-контейнер можно отпочковать от Parent и переопределить лишь некоторые реализации. Как использовать? Например, контроллер от своего контейнера отпочковывает ветку, делает изменения (убирает/добавляет логгер, заменяет какие-то сервисы, настройки) и сервисы, порождённые в этой ветке, уже имеют свой Environment. Никаких статиков, глобальных конфигов и синглетонов.
1. Контейнер — такой же сервис (используемый для получения сервисов). Поэтому его можно положить в контейнер, т.е. в себя же. Чем это хорошо? Ссылку на контейнер можно объявить dependency-свойством и тогда обращение к контейнеру не придётся делать через singleton, класс получит контейнер, как любой другой сервис.
2. DI-контейнер, который используется у нас (Microsoft Unity), позволяет строить дерево контейнеров. Child-контейнер можно отпочковать от Parent и переопределить лишь некоторые реализации. Как использовать? Например, контроллер от своего контейнера отпочковывает ветку, делает изменения (убирает/добавляет логгер, заменяет какие-то сервисы, настройки) и сервисы, порождённые в этой ветке, уже имеют свой Environment. Никаких статиков, глобальных конфигов и синглетонов.
* dependency-свойство = инжектированное свойство в терминологии Unity
Все инъекции представляют из себя только свойства(dependency-свойства)? Методы контейнера не могут отдавать инъекции? Как в этом случае реализуется ленивая инициализация сервисов?
Есть ещё синтаксис инъекций в параметры конструктора, но это лишний код — потом принятые параметры сохранять в переменные класса.
Желательно все инъекции оформлять через свойства (декларативныое описание зависимостей, не надо писать служебный код).
Но никто не мешает вручную из di-контейнера достать сервис или настроенный контроллер, если логика требует отложенной инициализации (такое почти никогда не надо, сервисы же не хранят состояние) или нужно в цикле 100500 контроллеров создать. При этом контейнер, из которого достаём, как любой другой сервис, должен быть в dependency.
Желательно все инъекции оформлять через свойства (декларативныое описание зависимостей, не надо писать служебный код).
Но никто не мешает вручную из di-контейнера достать сервис или настроенный контроллер, если логика требует отложенной инициализации (такое почти никогда не надо, сервисы же не хранят состояние) или нужно в цикле 100500 контроллеров создать. При этом контейнер, из которого достаём, как любой другой сервис, должен быть в dependency.
Любопытное замечание было в видеолекциях какого-то гуру di/IoC: несмотря на то, что IoC избавляет наши классы от зависимостей от классов другого слоя, он добавляет зависимость от контейнера. Можно написать свой интерфейс-обёртку вокруг библиотеки DI и менять её по своему усмотрению: сегодня Unity, завтра — ninject.
Sign up to leave a comment.
IT-компот #20 Подкаст о программировании и технологиях