Статическое определение отсутствующих зависимостей при использовании контейнера внедрения зависимостей

Question

При использовании контейнера внедрения зависимостей при выполнении разрешения обнаруживаются отсутствующие зависимости.Это во время выполнения.

В этой статье описывается частичное решение.Это помогло бы упростить тестирование, отладку и сопровождение, но все же требует выполнения тестов для проверки вашего поведения (особенно если вы используете абстрактное фабричное решение для разрешения времени выполнения):

http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

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

Answer 1

Managed Extensibility Framework (MEF) может сделать это. Есть некоторые рекомендации, которые необходимо соблюдать, чтобы анализ был точным, но в остальном результаты хорошие.

Для анализа набора сборок используется инструмент командной строки - см. http://blogs.msdn.com/b/nblumhardt/archive/2009/08/28/analyze-mef-assemblies-from-the-command-line.aspx. Это можно запустить из Visual Studio или сценария сборки на сервере непрерывной интеграции - http://blogs.msdn.com/b/nblumhardt/archive/2009/09/24/debug-composition-from-within-visual-studio.aspx.

Вы можете сделать это визуально (опять же через набор сборок), используя Visual MEFX проекта MefContrib - см. http://xamlcoder.com/blog/2010/04/10/updated-visual-mefx/

MEF поддерживает эту функцию, будучи очень декларативной (стандартные атрибуты для конфигурации) и используя базовую композиционную модель, которая работает лениво (она может строить график без создания каких-либо экземпляров ... Требуется немного времени, чтобы обернуть голову. )

Answer 2

Краткий ответ: нет, это невозможно.

Для этого потребуется возможность представлять все компоненты и их зависимости (метаданные контейнера) в виде графика для его анализа. Проблема в том, что чем сложнее контейнер, тем сложнее его достичь. Взять к примеру Виндзор. Его многочисленные точки расширения делают зависимости слишком динамичными, чтобы представлять их в виде графика. Ленивые загрузчики компонентов, селекторы обработчиков, фабрики, участники моделирования компонентов, субресольверы - все они участвуют в процессе и могут быть произвольным кодом пользователя, что делает невозможным статический анализ.

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

Так что, как обычно, это компромисс, и лучшее, что мы можем сделать, - это иметь несколько тестов, которые осуществляют фактическое разрешение всех зарегистрированных компонентов в контейнере. StructureMap имеет метод AssertConfigurationIsValid () для этого.

Несмотря на это, могут быть более тонкие ошибки, которые не могут быть обнаружены, например, проблемы образа жизни .

Answer 3

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

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

Answer 4

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

var foo = new Foo();
var bar = new Bar(foo);
var program = new Program(bar);
program.Run();

Если он компилируется, то все зависимости есть.

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