Выбор между MEF и MAF (System.AddIn)

Ответ 1

Я оценивал эти варианты и вот вывод, к которому я пришел.

MAF - это истинная структура аддона. Вы можете полностью разделить свои аддоны, даже запуская их в отдельном домене приложения, чтобы при сбое аддона он не удалял ваше приложение. Он также обеспечивает очень полный способ развязки аддонов из зависимости от чего угодно, кроме контракта, который вы им даете. Фактически вы можете использовать ваши адаптеры для адаптации к предыдущей совместимости со старыми аддонами при обновлении основного приложения. Хотя это звучит здорово, он поставляется с большой ценой, которую вы должны заплатить, чтобы пересечь приложения. Вы платите эту цену по скорости, а также за гибкость типов, которые вы можете отправлять туда и обратно.

MEF больше похож на инъекцию зависимостей с некоторыми дополнительными преимуществами, такими как открытость и... (рисует пробел на этом). Степень изоляции, которую имеет MAF, отсутствует в MEF. Это две разные рамки для двух разных вещей.

Ответ 2

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

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

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

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

Ответ 3

Разработал и отправил приложение MAF. Мои взгляды на MAF несколько измучены.

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

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

• Установка новых или обновление существующих компонентов во время работы приложения. AddIn может быть обновлен, пока приложение запущено, и обновления отображаются пользователю без проблем. Для этого вам нужно иметь AppDomains.

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

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

• Улучшен QA (только один QA один компонент за раз). Затем QA может тестировать и выпускать дефекты для одного бита функциональности. Тестовые примеры легче разрабатывались и внедрялись.

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

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

Ответ 4

На мой взгляд, две технологии фактически нацелены на очень разные варианты использования.

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

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

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

Ответ 5

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

В дополнение к точкам, сделанным другими ответами, звучит так, как будто одно из ключевых различий между MEF и MAF заключается в том, что Managed Extensibility Framework позволит одной составной части зависеть от другой. Например, плагин будет зависеть от другого плагина.

Рациональная платформа расширения также не делает различий между хостом и надстройкой, как это делает System.AddIn. Что касается MEF, все они просто составные части.

Ответ 6

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

MEF: Простой пример калькулятора с использованием частей MEF
(M anaged E расширяемость F)

• Показывает, как создать простой калькулятор с использованием технологии 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
(M anaged A ddin F)

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

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters
  

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

Ответ 7

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

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