Платформа управляемой расширяемости (MEF) и структура управляемых надстроек (MAF, также известная как System.AddIn), похоже, решают очень похожие задачи. Согласно этому вопросу о переполнении стека, Является ли MEF заменой System.Addin?, вы даже можете использовать оба одновременно.
Когда бы вы предпочли использовать одно против другого? При каких обстоятельствах вы бы решили использовать и то, и другое вместе?
Я оценивал эти варианты и вот к чему пришел.
MAF - это настоящая аддонная структура. Вы можете полностью разделить свои надстройки, даже запустив их в отдельном домене приложения, чтобы в случае сбоя надстройки оно не остановило ваше приложение. Он также предоставляет очень полный способ развязать аддоны от чего-либо, кроме контракта, который вы им даете. Фактически, вы можете управлять версиями своих контрактных адаптеров, чтобы обеспечить обратную совместимость со старыми надстройками при обновлении основного приложения. Хотя это звучит великолепно, это дорого обходится вам за пересечение доменов приложений. Вы платите эту цену за скорость, а также за гибкость типов, которые вы можете отправлять туда и обратно.
MEF больше похож на инъекцию зависимостей с некоторыми дополнительными преимуществами, такими как обнаруживаемость и ... (на этом рисуем пробел). Степень изоляции, которую имеет MAF, отсутствует в MEF. Это две разные структуры для двух разных вещей.
То, что сказал Дэниел, хорошо. Я бы добавил:
Если вы посмотрите видео о System.Addins, они явно говорят об очень больших проектах. Он говорит о том, что одна команда управляет хост-приложением, другая команда управляет каждой надстройкой, а третья команда управляет контрактом и конвейером. Исходя из этого, я думаю, что System.Addins явно предназначен для более крупных приложений. Я думаю о приложениях, таких как системы ERP, например SAP (может быть, не такие уж большие, но вы поняли). Если вы смотрели эти видео, то можете сказать, что объем работы по использованию System.Addins очень велик. Это было бы хорошо, если бы у вас было много компаний, разрабатывающих сторонние надстройки для вашей системы, и вы не могли бы разорвать ни один из этих контрактов надстройки под страхом смерти.
С другой стороны, MEF, похоже, имеет больше общего со схемой надстроек SharpDevelop, архитектурой надстроек Eclipse или Mono.Addins. Его гораздо легче понять, чем System.Addins, и я считаю, что он намного более гибкий. Что вы теряете, так это то, что вы не получаете изоляцию AppDomain или строгие контракты на управление версиями прямо из коробки с MEF. Сильные стороны MEF в том, что вы можете структурировать все свое приложение как состав частей, чтобы вы могли поставлять свой продукт в различных конфигурациях для разных клиентов, а если клиент покупает новую функцию, вы просто перетаскиваете часть для этой функции в их установочный каталог. и приложение его видит и запускает. Это также облегчает тестирование. Вы можете создать экземпляр объекта, который хотите протестировать, и передать ему имитационные объекты для всех его зависимостей, но когда он работает как составное приложение, процесс композиции автоматически объединяет все реальные объекты вместе.
Самым важным моментом, который я хотел бы упомянуть, является то, что хотя System.Addins уже находится в структуре, я не вижу много свидетельств того, что люди его используют, но MEF просто сидит на CodePlex, предположительно, для включения в .NET 4, и люди уже начинают создавать на нем множество приложений (включая меня). Я думаю, это кое-что говорит вам о двух фреймворках.
Разработав и отправив приложение MAF. Мои взгляды на MAF несколько пресыщены.
MAF - это "несвязанная" система или в худшем случае "слабосвязанная" система. MEF - это «связанная» система или, в лучшем случае, «слабосвязанная» система.
Преимущества MAF, которые мы реализовали с помощью MAF:
Установка новых или обновление существующих компонентов во время работы приложения. Надстройку можно обновлять во время работы приложения, и обновления отображаются для пользователя без проблем. Для этого у вас должны быть домены приложений.
Лицензирование на основе приобретенных компонентов. Мы могли контролировать, какие надстройки были загружены, с помощью роли и разрешений пользователя, а также была ли надстройка лицензирована для использования.
Быстрое развитие (более быстрый вывод на рынок). Разработка надстроек идеально сочетается с методологией Agile, команда разработчиков разрабатывала по одной надстройке за раз, без необходимости также разрабатывать компонент интеграции с остальной частью приложения.
Улучшенный QA (только QA по одному компоненту за раз). Затем QA может протестировать и выявить дефекты для одного бита функциональности. Тестовые примеры было проще разрабатывать и внедрять.
Развертывание (добавляйте компоненты по мере их разработки и выпуска, и они «просто работают»). Развертывание сводится только к созданию надстройки и установке файла. Никаких других соображений не потребовалось!
Новые компоненты работали со старыми компонентами. Надстройки, которые были разработаны на раннем этапе, продолжали работать. Новые надстройки легко вписываются в приложение
На мой взгляд, две технологии на самом деле нацелены на очень разные варианты использования.
MEF обычно лучше всего подходит для сценария чистой инъекции зависимостей, когда человек или группа, доставляющие окончательное интегрированное решение, собирают все и ручаются за общую целостность, но нуждаются в различных реализациях ключевых возможностей.
MAF предназначен для сценария, когда кто-то / группа разрабатывает платформу или хост, а другие группы добавят возможности постфактум и способом, не находящимся под контролем группы хостов. В этом сценарии необходимы более сложные механизмы для «защиты» хоста от мошеннических надстроек (или защиты надстроек друг от друга).
Третья похожая по шаблону технология - это вся схема ProviderBase. Это также позволяет заменить возможность, но на самом деле ее целью является сценарий, в котором хосту / приложению абсолютно необходима возможность, и действительно необходимо указать различные реализации через config.
Я только что нашел эту длинную статью, в которой обсуждаются как MAF, так и MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/
В дополнение к пунктам, высказанным в других ответах, похоже, что одно из ключевых различий между MEF и MAF заключается в том, что структура управляемой расширяемости позволяет одной компонуемой части зависеть от другой. Например, это позволит подключаемому модулю зависеть от другого подключаемого модуля.
Платформа управляемой расширяемости также не делает различий между хостом и надстройкой, как это делает System.AddIn. Что касается MEF, все они просто составные части.
На мой взгляд, лучший способ обнаружить различия - это написать практический код. Я нашел два пошаговых руководства MSDN, оба с примером калькулятора, чтобы вы могли легко сравнить их реализации:
MEF: Пример простого калькулятора с использованием частей MEF
(M расширяемость F ramework)
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: Простой калькулятор с Плагины MAF
версий V1 и V2 (M аннулированный A ddin F ramework)
Pipeline AddIns CalcV1 CalcV2 AddInSideAdapters AddInViews Contracts HostSideAdapters
И MEF, и MAF включены в .NET Framework 4.x. Если вы сравните два примера, то заметите, что плагины MAF намного сложнее, чем фреймворк MEF, поэтому вам нужно хорошо подумать, когда использовать какую из этих фреймворков.
MAF и MEF могут использовать домены приложений, и оба могут загружать / выгружать dll во время выполнения. Однако я обнаружил следующие отличия: дополнительные модули MAF не связаны, компоненты MEF слабо связаны; MAF «активирует» (новый экземпляр), в то время как MEF создает экземпляры по умолчанию.
С MEF вы можете использовать Generics для создания GenericHost для любого контракта. Это означает, что загрузка / выгрузка MEF и управление компонентами могут находиться в общей библиотеке и использоваться универсально.
