Использование MEF в качестве IoC - PullRequest
15 голосов
/ 20 июля 2010

После прочтения некоторых вещей, таких как это: http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html

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

Мне нужен материал MEF.Нужно ли мне также IoC-фреймворк, или мне будет хорошо с тем, что есть у MEF?

Asher

Ответы [ 5 ]

8 голосов
/ 20 июля 2010

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

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

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

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

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

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

Дайте мне знать, если у вас есть какие-либо вопросы:)

3 голосов
/ 20 июля 2010

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

При этом вам следует взглянуть на это сообщение в блоге Гленна Блока, где он перечисляет недостатки, с которыми вы можете столкнуться: Должен ли я использовать MEF для своих общих потребностей в IoC?

3 голосов
/ 20 июля 2010

IoC следует за целью.

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

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

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

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

для плагинов -> MEF

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

2 голосов
/ 28 июля 2010

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

1 голос
/ 13 декабря 2011

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

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

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

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

...