Выбор между MEF и MAF (система.надстройка)

то, что сказал Даниэль, хорошо. Я бы добавил:

Если вы смотрите видео о системе.Аддины, они явно говорят об очень больших проектах. Он говорит об одном команда управление приложения, другой команда управление каждой надстройкой, и третий команда управление контрактом и трубопроводом. Исходя из этого, я думаю, что система.Надстройки явно для больших приложений. Я думаю, что такие приложения, как ERP-системы, такие как SAP (возможно не такой большой, но вы получите идею). Если вы смотрели эти видео вы можете сказать, что объем работы, чтобы использовать систему.Плагинов очень большой. Это будет хорошо работать, если у вас было много компаний, программирующих сторонние надстройки для вашей системы, и вы не можете нарушить ни один из этих контрактов надстройки под страхом смерти.

с другой стороны, MEF, похоже, имеет больше общего со схемой надстройки SharpDevelop, архитектурой плагина Eclipse или Mono.Надстройки. Это гораздо проще понять чем система.Аддины и я считаю, что это будет намного более гибким. То, что вы теряете,-это то, что вы не получаете изоляцию AppDomain или сильные контракты на управление версиями из коробки с MEF. Сильные стороны MEF заключаются в том, что вы можете структурировать все свое приложение как композицию деталей, поэтому вы можете отправлять свой продукт в разных конфигурациях для разных клиентов, и если клиент покупает новую функцию, вы просто бросаете часть для этой функции в свой каталог установки, и приложение видит ее и запускает его. Это также облегчает тестирование. Вы можете создать экземпляр объекта, который хотите протестировать, и передать ему макетные объекты для всех его зависимостей, но когда он запускается как составное приложение, процесс композиции автоматически связывает все реальные объекты вместе.

самый важный момент, который я хотел бы отметить, что хотя система.Аддины уже находятся в рамках, Я не вижу много доказательств того, что люди используют его, но MEF просто сидит там на CodePlex, предположительно, чтобы быть входит в .NET 4, и люди уже начинают строить много приложений с ним (включая меня). Я думаю, что это говорит вам что-то о двух фреймворках.

имея подготовлены и отправлены заявки на МАФ. Мои взгляды на МАФ несколько пресыщены.

MAF-это" де-связанная "система или" слабо связанная " система в худшем случае. MEF - это "связанная" система или" слабо-пара " система в лучшем случае.

MAF преимущества, которые мы поняли с помощью MAF являются:

1. установка новых или обновление существующих компонентов во время выполнения приложения. Надстройка может быть обновлена во время работы приложения и обновления появляются для пользователя легко. Для этого у вас должны быть Домены приложений.

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

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

4. улучшение качества (только один компонент ОК на время). QA смогло после этого испытать и выдать дефекты для одиночного бита функциональности. Тестовые примеры было легче разрабатывать и внедрять.

5. развертывание (добавьте компоненты по мере их разработки и выпуска, и они "просто работают"). Развертывание-это только вопрос создания надстройки и установки файла. Никаких других соображений не было необходимо!

6. новые компоненты работали со старыми компонентами. AddIn, которые были разработаны на ранней стадии продолжал работать. Новые дополнения вписываются в приложение легко

на мой взгляд эти две технологии на самом деле цель очень разных ситуациях.

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

MAF - это сценарий, в котором кто-то/группа разрабатывает платформу или хост, а другие группы будут добавлять возможности ведь и в каком-то смысле не под контролем группы хозяев. В этом сценарии необходимы более сложные механизмы для "защиты" хоста от вредоносных надстроек (или для защиты надстроек друг от друга).

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

Я только что нашел эту длинную статью, обсуждающую как MAF, так и MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

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

в Управляемая платформа расширяемости также не делает различий между хостом и надстройкой, как и система.Надстройка делает. Что касается MEF, они все просто составные части.

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

MEF:простой пример калькулятора с помощью MEF parts
(Managed E xtensibility Framework)

• показывает, как создать простой калькулятор с использованием технологии MEF. Не показывает, как загрузить внешние библиотеки DLL. (Но вы можете просто изменить пример с помощью catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll")); вместо того, чтобы использовать catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); и извлечения код калькулятора и контракт для разделения проектов DLL.)

• MEF не нужно иметь определенную структуру каталогов, она проста и понятна в использовании, даже для небольших проектов. Это работает с атрибутами, чтобы объявить, что экспортируется, что легко читать и понимать. пример: [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF не работает автоматически с версиями

MAF:простой калькулятор с версией V1 и V2 MAF Плагины
(Managed Addin Framework)

• показывает, как создать калькулятор с помощью плагина V1, а затем как перейти к плагину V2 при сохранении обратная совместимость (Примечание: вы можете найти версию V2 плагина здесь, ссылка в оригинальной статье сломана)
• MAF обеспечивает конкретной структура каталогов, а для этого нужно много шаблонного кода, чтобы заставить его работать, поэтому я не рекомендую его для небольших проектов. пример:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters
  

оба MEF и MAF включены в .NET Framework 4.x. Если вы сравниваете два примера, вы заметите, что плагины MAF имеют гораздо большую сложность по сравнению с MEF framework - поэтому вам нужно тщательно подумать, когда использовать какой из этих фреймворков.

MAF и MEF оба могут использовать AppDomains и оба могут загружать/выгружать dll во время выполнения. Однако различия, которые я нашел, таковы: надстройки MAF развязаны, компоненты MEF свободно связаны; MAF "активирует" (новый экземпляр), в то время как MEF делает экземпляры по умолчанию.

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