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