В прошлом году я создал новую систему, используя Dependency Injection и контейнер IOC. Это научило меня много о DI!
Однако даже после изучения концепций и правильных шаблонов я считаю сложной задачей отделить код и внедрить контейнер IOC в устаревшее приложение. Приложение достаточно велико до такой степени, что истинная реализация будет подавляющей. Даже если ценность была понята и время было предоставлено. Кому предоставлено время для чего-то подобного?
Цель курса - привести юнит-тесты в бизнес-логику!
Бизнес-логика, которая переплетается с вызовами базы данных для предотвращения тестирования.
Я прочитал статьи и понимаю опасности инъекций зависимостей бедного человека, как описано в этой статье в Los Techies . Я понимаю, что на самом деле ничего не отделяет.
Я понимаю, что это может повлечь за собой значительный системный рефакторинг, поскольку реализации требуют новых зависимостей. Я бы не стал использовать его в новом проекте любого размера.
Вопрос: Можно ли использовать DI для «Бедного человека», чтобы ввести тестируемость в унаследованное приложение и начать работу?
Кроме того, является ли использование DI Бедного человека в качестве низового подхода к истинной инъекции зависимостей ценным способом разъяснить необходимость и преимущества принципа?
Можете ли вы провести рефакторинг метода, который имеет зависимость от вызовов базы данных и абстрагировать этот вызов за интерфейсом? Простая абстракция сделает этот метод тестируемым, поскольку фиктивная реализация может быть передана через перегрузку конструктора.
В будущем, как только усилия получат поддержку, проект может быть обновлен для реализации контейнера IOC, и там будут конструкторы, которые принимают абстракции.
I consider it a challenge to decouple code and introduce an IOC container into a legacy application
конечно это. Это называется технический долг. Вот почему перед любым серьезным обновлением предпочтительнее небольшой и непрерывный рефакторинг. Сокращение основных недостатков дизайна и переход на IoC будет менее сложным.Ответы:
Критика в отношении инъекции для Бедного в NerdDinner связана не столько с тем, используете ли вы DI-контейнер, сколько с правильной настройкой классов.
В статье говорится, что
неверно, потому что, хотя первый конструктор предоставляет удобный резервный механизм для создания класса, он также создает тесно связанную зависимость
DinnerRepository
.Разумеется, правильное решение проблемы заключается не в том, чтобы добавить контейнер DI, а в том, чтобы удалить конструктор-нарушитель.
У оставшегося класса теперь его зависимости должным образом инвертированы. Теперь вы можете вводить эти зависимости так, как вам нравится.
источник
XService
передает параметр вXRepository
и возвращает то, что он возвращает, не слишком полезно для всех и не дает вам больших возможностей расширения. Напишите свои модульные тесты, чтобы проверить осмысленное поведение и убедиться, что ваши компоненты не настолько узки, что вы фактически переносите всю свою логику в корень композиции.Вы делаете ложное предположение о том, что такое «DI бедняков».
Создание класса с конструктором «ярлык», который по-прежнему создает связь , не является DI бедняков.
Не используя контейнер, и создавая все уколы и отображение вручную, является это DI бедного человека.
Термин «DI бедного человека» звучит как плохой поступок. По этой причине в наши дни поощряется термин «чистый ДИ». поскольку он звучит более позитивно и фактически более точно описывает процесс.
Мало того, что совершенно нормально использовать DI «бедняков» / «чистый человек» для введения DI в существующее приложение, это также правильный способ использования DI для многих новых приложений. И, как вы говорите, каждый должен использовать чистый DI хотя бы в одном проекте, чтобы по-настоящему понять, как работает DI, прежде чем переложить ответственность на «магию» контейнера IoC.
источник
Смена парадигмы в устаревших командах / основах кода чрезвычайно рискованна:
Использование DI Framework в качестве молотка для того, чтобы разбить все гвозди, во всех случаях просто сделает устаревший код хуже, чем лучше. Это также чрезвычайно рискованно лично.
Даже в самых ограниченных случаях, таких как просто так, его можно использовать в тестовых примерах, просто сделает те тестовые случаи «нестандартным» и «чужим» кодом, который в лучшем случае будет просто помечен,
@Ignore
когда они ломаются или хуже, постоянно жаловаться Устаревшие программисты, обладающие наибольшим влиянием на управление и переписываемые «правильно» со всем этим «потерянным временем на модульных тестах», обвиняются исключительно в вас.Внедрение зависимостей - это решение проблемы.
Инъекция зависимости полезна только в малых дозах для очень узкого диапазона вещей:
Вещи, которые сильно меняются или имеют множество альтернативных реализаций, которые статически связаны.
Системы плагинов, которые имеют настраиваемые плагины, которые могут быть определены в коде конфигурации в вашей среде и обнаружены автоматически при запуске и динамически загружаться / перезагружаться во время работы программы.
источник