По каким техническим причинам следует избегать внедрения сервисного контейнера вместо отдельных сервисов?

Question

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

Answer 1

Если вы внедрите контейнер, вы не сделаете ясными зависимости.На самом деле, вы скрываете их больше, чем раньше.Если у вас есть такой класс ...

class DocumentCreator(IFileNamer fileNamer, IRepository repository)
{ ... }

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

class DocumentCreator(IDependencyContainer container)
{ ... }

... вы скрыли зависимости.Без изучения внутренних элементов класса вы не можете знать, что для этого требуются IFileNamer и IRepository.

Также вы не можете легко узнать, какие макеты нужно поместить в контейнер для тестирования DocumentCreator.Дразнить IDependencyContainer вам совсем не поможет;ваш класс все равно не пройдёт тестирование, потому что контейнер не будет содержать IFileNamer и IRepository, если вы не изучите внутреннее содержимое класса, чтобы убедиться, что они необходимы.

Answer 2

То, что вы описываете, является ServiceLocator.Это считается анти-паттерном в современном дизайне приложений. Эта статья описывает почему.

Answer 3

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