MEF VS Unity - разрешение зависимостей во время выполнения - PullRequest
Новая
       27

MEF VS Unity - разрешение зависимостей во время выполнения

2 голосов
/ 27 ноября 2011

Я сравнивал Unity и MEF (для использования в Prism) и шел к MEF. Увы, недавно я увидел отличное разрешение зависимостей во время выполнения Unity - если я хочу добавить модуль, я должен просто добавить его тип view, используя ServiceLocator, и, если у меня есть конструктор зависимостей, указывающий view model, Unity инициализирует его для меня, вместе с зависимостями виртуальной машины (в других сервисах и модулях).

Поддерживается ли такое поведение в MEF?

Спасибо.

1 Ответ

8 голосов
/ 30 ноября 2011

Давайте пока проигнорируем Unity и MEF и посмотрим, что вы описываете.

если у меня есть конструктор зависимостей, указывающий view model, Unity инициализирует его для меня вместе с зависимостями виртуальной машины (в других сервисах и модулях).

Этот механизм называется Внедрение зависимостей (DI) и является реализацией принципа Inversion of Control (IoC) . Также обратите внимание, что DI не совпадает с Расположение службы (SL) .

Ваш конкретный пример называется внедрение конструктора , в результате чего зависимости вводятся в конструируемый тип, поэтому: 

public MyView(MyViewModel viewModel) { }

Является ли сайт для конструктора инъекций. Теперь давайте посмотрим на две разные контейнерные технологии:

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

MEF основан на обнаружении и составлении неизвестных частей , т. Е. Он создает свой контейнер, формируя список из экспортных поставщиков (либо каталогов, либо других поставщиков). Когда вы запрашиваете составную часть, она по умолчанию выберет конструктор без параметров, например ::101031 

public MyView() { }

Если вы не украсите целевой конструктор атрибутом [ImportingConstructor], который позволит MEF выбрать соответствующий конструктор и разрешить любые зависимости: 

[ImportingConstructor]
public MyView(MyViewModel viewModel) { }

Также обратите внимание, что MEF поддерживает внедрение свойства - [Import] и [ImportMany] атрибуты: 

[Import]
public MyViewModel ViewModel { get; set; }

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

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

Короче говоря, да вы можете использовать MEF для внедрения зависимостей.

...