После прочтения некоторых вещей, таких как: http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html
Я понимаю, что у MEF есть некоторые featcures, которые я не найду в IoC, и что у MEF есть некоторые материалы IoC, которые, вероятно, не настолько продвинуты, как могут предложить некоторые другие системы IoC.
Мне нужен материал MEF. Мне также нужна инфраструктура IoC, или мне будет хорошо, что у MEF?
Ашер
В зависимости от ваших требований/существующего кода.
Если у вас есть существующая инфраструктура кода, построенная на контейнере 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 может обрабатывать инъекцию свойств, впрыск конструктора, управление жизненным циклом части и разрешение типа.
Сообщите мне, если у вас есть вопросы:)
IoC следует цели.
MEF специально разработан, если вы хотите иметь какие-то плагины в своей системе. или код, которому вы не доверяете, чтобы нормально работать (не забывайте обрабатывать исключения).
но, следовательно, это связано с накладными расходами.
Если вы просто хотите сделать IoC, так как это хороший шаблон дизайна для расширяемого и тестируемого программного обеспечения, тогда я бы порекомендовал AutoFac, как и от того же парня. более или менее: -)
и, если вам нужны оба намерения. затем используйте Both. как отметил Матфей, вы можете использовать CSL для абстрагирования обоих. если захотите.
для плагинов → MEF
для вашего IoC → простой IoC
Мы используем MEF как контейнер IoC, и он работает для нас.
Сказав это, вы должны взглянуть на это сообщение в блоге Glenn Block, в котором перечислены недостатки, с которыми вы можете столкнуться: Должен ли я использовать MEF для моего общие потребности IoC?
Я использую MEF как для расширяемости, так и для IoC в SoapBox Core. Там также статья о CodeProject под названием Создание расширяемого приложения с MEF, WPF и MVVM, описывающее, как это работает.
Я использовал модель провайдера по существу "IOC" в веб-приложении до того, как в последнее время переключился на AutoFac.
В основном, мое требование состоит в том, что мне нужно иметь возможность "продавать" приложения, поэтому любые интерфейсы нужно абстрагировать. При использовании модели провайдера вещи, как правило, становятся беспорядочными. Использование контейнера IOC (если вы уже есть) имеет больше смысла, и я все еще могу отвечать моим требованиям "on-selling", потому что контейнер IOC можно "переконфигурировать", чтобы разрешить различные реализации.
Я думаю, что MEF будет лучшим решением, если вы хотите получить чистую базу кода, потому что у нее больше соглашений, поэтому по существу люди могут отбрасывать компоненты в папке и не изменять какую-либо конфигурацию, чтобы инициировать изменения. Это хорошо, но, возможно, слишком велико для моего сценария, где достаточно простого переопределения конфигурации.
Подробнее о моем сообщении в блоге - надеюсь, блог также получит хорошие комментарии об этом: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html