Получил недавно письмо с вопросом, использую ли я в своих проектах Dependency Injection. Обратного адреса не было, но и не нужно, ответ на такой вопрос желательно наверно дать на блоге, думаю, что это будет интересно многим.
Да, конечно же я использую Dependency Injection. Без этого писать юнит тесты проблематично, особенно, если приходится работать с Web сервисами. Как раз из-за них я впервые много лет назад я познакомился с этим патерном. Так что достаточно много приходится использовать интерфейсы и инъекцию.
Использую ли я какие-то библиотеки? Нет. Для инициализации и инъекции пишу свой код. Во-первых, это не так уж и сложно, во-вторых я люблю все же все контролировать. На мой взгляд, автоматические библиотеки не так уж и много дают преимуществ и не так уж и сильно упрощают жизнь.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
DI используют все. Так как это просто передача зависимости. Даже без интерфейса.
А вот если передается высокоуровневая абстракция, это уже DIP (Принцип инверсии зависимости, один из SOLID принципов), то есть переход от композиции к агрегации. Зависимость жестко не привязана по времени жизни.
Да но контейнеры упрощают жизнь, ведь не вы управляете зависимости, а настроенный контейнер управляет всем жизненным циклом. То есть происходит инверсия управления IoC.
Я считаю, что библиотеки несут в себе кучу плюсов. Во-первых можно задать время жизни (Singleton, Transient, PerPequest), что очень удобно. Во-вторых MVC имеет интеграцию с DI и может внедрять зависимости в контроллеры автоматом. В-третьих они умеют внедрять в Lazy тем самым инстанс будет создаваться только по требованию ну и куча других преимуществ.
Немного не соглашусь с уважаемым Overdrive - хоть и не Фаулер, но придерживаюсь мнения что dependecy injection это одна из реализаций Inversion of Control и в случае, происходит ли передача высокоуровневой абстракции, или просто класа - сдесь не играет никакой роли. Это просто одна из реализаций IoC. По поводу контейнеров - все зависит от ситуации. Ничто в простых приложения не мешает делать классы слабосвязаними самому (как было сказато выше, леер тестирования от этого только выиграет) но в тоже время, деньги нам платят не за создания велосипеда, если есть что то что нас вполне устраивает по функционалу, то ИМХО оно уже оттестировано и оно будет работать значительно стабильнее чем самописное. Я не вижу смысла со стороны кастомера платить за "создание чего то" нового что даст только с субьективной стороны розработчика какието плюсы.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
