MEF Global CompositionContainer в существующих приложениях

Я исследую MEF как решение для разрешения плагинов в нашем существующем приложении .NET.

Во всех примерах, которые я могу найти, основное приложение создает экземпляр CompositionContainer и вызывает container.ComposeParts (this).

Проблема в том, что мое приложение не полностью построено на MEF, поэтому в графе объектов есть дыра, в которой нет компонентов MEF. Итак, моя иерархия объектов может выглядеть так:

Приложение (контейнер MEF) -> ObjectB (без MEF) -> ObjectA (требуется импорт MEF)

В этой иерархии объектов я не могу вызвать container.ComposeParts (this) в приложении и ожидать, что приложение создаст ObjectB и удовлетворит Imports ObjectA.

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


.net composition mef
person Joshua Starner    schedule 29.06.2010    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Является ли хорошей практикой выставлять CompositionContainer глобально?

Я бы не назвал это хорошей практикой, но это разумный компромисс, когда невозможно повсеместно внедрить инверсию принципа управления для строительства. Иногда существующая кодовая база не полностью находится под вашим контролем, или представляет собой сложное сочетание .NET и собственного кода (например, компоненты COM), или просто слишком велика для рефакторинга.

В Silverlight создание объектов из XAML также находится вне контроля MEF, поэтому Microsoft представила по существу такое же решение: контейнер MEF по умолчанию доступен как глобальный и вызывается с помощью PartInitializer.SatisfyImports(this);.

Обратите внимание, что следование этому шаблону будет тесно связывать всех потребителей глобального с MEF и глобальной переменной, используемой для его предоставления. Невозможно повторно использовать этот код как есть в других приложениях или с другими контейнерами IoC. Это также усложнит модульное тестирование.

person Wim Coenen    schedule 29.06.2010