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