Выбор между MEF и MAF (System.Дополнение)

StackOverflow https://stackoverflow.com/questions/835182

Вопрос

Платформа управляемой расширяемости (MEF) и платформа управляемых дополнений (MAF, она же System.AddIn), похоже, решают очень похожие задачи.В соответствии с этим вопросом о переполнении стека, Является ли MEF заменой System.Addin?, вы даже можете использовать и то, и другое одновременно.

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

Это было полезно?

Решение

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

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

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

Другие советы

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

Если вы смотрите видео о 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, и люди уже начинают создавать множество приложений с ним (включая меня). Я думаю, что это говорит вам кое-что о двух платформах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

МЕФ: Простой пример использования калькулятора Части MEF
(Mанагед Eрасширяемость Fрамная работа)

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

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

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

МАФ: Простой калькулятор с версиями V1 и V2 Плагины MAF
(Mанагед Addin Fрамная работа)

  • Показывает, как создать калькулятор с помощью плагина версии V1, а затем как перейти к плагину версии V2 с сохранением обратной совместимости (примечание: вы можете найти версию плагина V2 здесь, ссылка в оригинальной статье не работает)
  • МАФ принуждает конкретный структура каталогов, и для того, чтобы заставить его работать, требуется много шаблонного кода, поэтому я не рекомендую его для небольших проектов.Пример: 
    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 и управление компонентами могут быть в общей библиотеке и использоваться в общем.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top