Является ли инъекция зависимостей бедного человека хорошим способом ввести тестируемость в устаревшее приложение?

В прошлом году я создал новую систему, используя Dependency Injection и контейнер IOC. Это научило меня много о DI!

Однако даже после изучения концепций и правильных шаблонов я считаю сложной задачей отделить код и внедрить контейнер IOC в устаревшее приложение. Приложение достаточно велико до такой степени, что истинная реализация будет подавляющей. Даже если ценность была понята и время было предоставлено. Кому предоставлено время для чего-то подобного?

Цель курса - привести юнит-тесты в бизнес-логику!
Бизнес-логика, которая переплетается с вызовами базы данных для предотвращения тестирования.

Я прочитал статьи и понимаю опасности инъекций зависимостей бедного человека, как описано в этой статье в Los Techies . Я понимаю, что на самом деле ничего не отделяет.
Я понимаю, что это может повлечь за собой значительный системный рефакторинг, поскольку реализации требуют новых зависимостей. Я бы не стал использовать его в новом проекте любого размера.

Вопрос: Можно ли использовать DI для «Бедного человека», чтобы ввести тестируемость в унаследованное приложение и начать работу?

Кроме того, является ли использование DI Бедного человека в качестве низового подхода к истинной инъекции зависимостей ценным способом разъяснить необходимость и преимущества принципа?

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

В будущем, как только усилия получат поддержку, проект может быть обновлен для реализации контейнера IOC, и там будут конструкторы, которые принимают абстракции.

Критика в отношении инъекции для Бедного в NerdDinner связана не столько с тем, используете ли вы DI-контейнер, сколько с правильной настройкой классов.

В статье говорится, что

public class SearchController : Controller {

    IDinnerRepository dinnerRepository;

    public SearchController() : this(new DinnerRepository()) { }

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

неверно, потому что, хотя первый конструктор предоставляет удобный резервный механизм для создания класса, он также создает тесно связанную зависимость DinnerRepository.

Разумеется, правильное решение проблемы заключается не в том, чтобы добавить контейнер DI, а в том, чтобы удалить конструктор-нарушитель.

public class SearchController : Controller 
{
    IDinnerRepository dinnerRepository;

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

У оставшегося класса теперь его зависимости должным образом инвертированы. Теперь вы можете вводить эти зависимости так, как вам нравится.

Вы делаете ложное предположение о том, что такое «DI бедняков».

Создание класса с конструктором «ярлык», который по-прежнему создает связь , не является DI бедняков.

Не используя контейнер, и создавая все уколы и отображение вручную, является это DI бедного человека.

Термин «DI бедного человека» звучит как плохой поступок. По этой причине в наши дни поощряется термин «чистый ДИ». поскольку он звучит более позитивно и фактически более точно описывает процесс.

Мало того, что совершенно нормально использовать DI «бедняков» / «чистый человек» для введения DI в существующее приложение, это также правильный способ использования DI для многих новых приложений. И, как вы говорите, каждый должен использовать чистый DI хотя бы в одном проекте, чтобы по-настоящему понять, как работает DI, прежде чем переложить ответственность на «магию» контейнера IoC.

Смена парадигмы в устаревших командах / основах кода чрезвычайно рискованна:

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

Использование DI Framework в качестве молотка для того, чтобы разбить все гвозди, во всех случаях просто сделает устаревший код хуже, чем лучше. Это также чрезвычайно рискованно лично.

Даже в самых ограниченных случаях, таких как просто так, его можно использовать в тестовых примерах, просто сделает те тестовые случаи «нестандартным» и «чужим» кодом, который в лучшем случае будет просто помечен, @Ignoreкогда они ломаются или хуже, постоянно жаловаться Устаревшие программисты, обладающие наибольшим влиянием на управление и переписываемые «правильно» со всем этим «потерянным временем на модульных тестах», обвиняются исключительно в вас.

Внедрение DI-фреймворка или даже концепции «Pure DI» в линейку бизнес-приложений, не говоря уже об огромной унаследованной кодовой базе без участия руководства, команды и, в особенности, спонсорства ведущего разработчика, станет смертельным звоном. для вас социально и политически в команде / компании. Делать подобные вещи крайне рискованно и в худшем случае может быть политическим самоубийством.

Внедрение зависимостей - это решение проблемы.

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

Инъекция зависимости полезна только в малых дозах для очень узкого диапазона вещей:

• Вещи, которые сильно меняются или имеют множество альтернативных реализаций, которые статически связаны.

  • Драйверы JDBC являются прекрасным примером.
  • HTTP-клиенты, которые могут отличаться от платформы к платформе.
  • Системы ведения журналов, которые зависят от платформы.

• Системы плагинов, которые имеют настраиваемые плагины, которые могут быть определены в коде конфигурации в вашей среде и обнаружены автоматически при запуске и динамически загружаться / перезагружаться во время работы программы.