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

Question

Среда Managed Extensibility Framework (MEF) и Managed AddIn Framework (MAF, иначе System.AddIn), по-видимому, выполняют очень похожие задачи. Согласно этому вопросу переполнения стека, Является ли MEF заменой System.Addin? , вы можете даже использовать оба одновременно.

Когда бы вы выбрали один против другого? При каких обстоятельствах вы бы хотели использовать оба вместе?

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters
  

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

Answer 7

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

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