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

Question

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

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

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

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

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

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

Answer 1

Это хорошая практика разоблачать КомпозицияКонтейнер по всему миру

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

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

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