Использование MEF в качестве IoC

Ответ 1

В зависимости от ваших требований/существующего кода.

Если у вас есть существующая инфраструктура кода, построенная на контейнере IoC, вы можете объединить их с MEF. Недавно я создавал структуру ASP.NET MVC + MEF, и несколько моих читателей спрашивали, как интегрировать Unity с созданной мной структурой MEF + MVC. Это оказалось очень простым, благодаря проекту, который называется Локатор общих служб.

Проект CSL предназначен для обеспечения абстракции над местоположением службы, поэтому я могу захватить поставщика CSL для Unity, подключить его к пользовательскому ExportProvider, а MEF автоматически начнет составлять мои компоненты, управляемые IoC.

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

На прошлой неделе Я писал о объединении MEF + Unity (а также MEF + Autofac в качестве другого примера), и хотя мои примеры настроены для ASP.NET MVC эта концепция для большинства других реализаций одинакова.

Если у вас есть возможность создать что-то новое с помощью MEF, вы, вероятно, обнаружите, что вам не нужен контейнер IoC, MEF может обрабатывать инъекцию свойств, впрыск конструктора, управление жизненным циклом части и разрешение типа.

Сообщите мне, если у вас есть вопросы:)

Ответ 2

IoC следует цели.

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

но, следовательно, это связано с накладными расходами.

Если вы просто хотите сделать IoC, так как это хороший шаблон дизайна для расширяемого и тестируемого программного обеспечения, тогда я бы порекомендовал AutoFac, как и от того же парня. более или менее: -)

и, если вам нужны оба намерения. затем используйте Both. как отметил Матфей, ​​вы можете использовать CSL для абстрагирования обоих. если захотите.

для плагинов → MEF

для вашего IoC → простой IoC

Ответ 3

Мы используем MEF как контейнер IoC, и он работает для нас.

Сказав это, вы должны взглянуть на это сообщение в блоге Glenn Block, в котором перечислены недостатки, с которыми вы можете столкнуться: Должен ли я использовать MEF для моего общие потребности IoC?

Ответ 4

Я использую MEF как для расширяемости, так и для IoC в SoapBox Core. Там также статья о CodeProject под названием Создание расширяемого приложения с MEF, WPF и MVVM, описывающее, как это работает.

Ответ 5

Я использовал модель провайдера по существу "IOC" в веб-приложении до того, как в последнее время переключился на AutoFac.

В основном, мое требование состоит в том, что мне нужно иметь возможность "продавать" приложения, поэтому любые интерфейсы нужно абстрагировать. При использовании модели провайдера вещи, как правило, становятся беспорядочными. Использование контейнера IOC (если вы уже есть) имеет больше смысла, и я все еще могу отвечать моим требованиям "on-selling", потому что контейнер IOC можно "переконфигурировать", чтобы разрешить различные реализации.

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

Подробнее о моем сообщении в блоге - надеюсь, блог также получит хорошие комментарии об этом: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html