Як ви використовуєте керовану рамку розширення?

Я працюю з МЕФ близько 2 тижнів. Я почав думати про те, для чого призначений MEF, досліджуючи, щоб дізнатися, як використовувати MEF, і, нарешті, впровадити хост з 3 модулями. Контракти виявляються легко зрозумітими, а модулями легко управляти.

Хоча MEF має дуже практичне використання, мені цікаво, якою мірою? Я маю на увазі, чи всі будуть переписувати наявні програми для розширення?

Так, це звучить, і це шалено непрактично. Риторично кажучи:

• як MEF впливає на сучасні тенденції в програмуванні?

• Ви почали шукати можливості використовувати MEF?

• Ви почали планувати капітальне перезапис існуючого додатка, який може отримати користь від розширення?

Це
означає , що мої запитання: як мені знати, коли я повинен планувати новий проект з розширенням?
як я дізнаюся, чи потрібно переробити існуючий проект для розширення?

Хтось використовує MEF?

Хтось використовує MEF?

Я працюю над проектом Silverlight за схемою MVVM. Ми розпочали, просто підключивши всі VM разом, за необхідності, через інтерфейси та ручне введення залежності (або конструктор, або введення властивості залежно від потреби). Це стало болісно, ​​і ми почали використовувати MEF як основу системи введення залежностей для експорту певних служб, які використовуються в різних моделях перегляду, та імпортування їх у моделі перегляду, які їм потрібні. Працює ідеально і з дуже невеликим кодом.

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

як мені знати, коли я повинен планувати новий проект з розширенням? як я дізнаюся, чи потрібно переробити існуючий проект для розширення?

ІМО, ви завжди повинні відповідним чином розділяти проблеми та використовувати інтерфейси, щоб різні модулі могли змінюватися самостійно. Якщо ви зробите це правильно, тоді, коли виявите потребу в розширюваності, MEF має бути легко додати. Але я б не запускав проект, який не мав вимог щодо розширення, і ставив MEF на всякий випадок. Я б зачекав, коли буде потреба. Для існуючих проектів, якщо виникає потреба, я б оцінив зусилля, щоб перепрофілювати проект, щоб використовувати MEF проти альтернативних рішень проти нічого не робити, і побачити, що виграє.

Помилка, яку роблять люди, і я вважаю, що це пов'язано з називанням (керована рамка розширюваності ) в тому, що MEF є практичним лише для розширення. MEF дійсно вирішує три ключові речі: розширюваність, виявлення та метадані. Останні два дуже потужні навіть для програми, яка ніколи не побачить жодного плагіна чи розширення.

Це стаття, яку я писав про те, що це сила для відкриття як контейнера МОК: http://www.informit.com/articles/article.aspx?p=1635818

Я використовую MEF у більшості корпоративних ліній ділових додатків, оскільки це дозволяє швидше і простіше будувати та підтримувати модульні програми в Silverlight.

В даний час я використовую MEF в кількох проектах, що містять схему репозиторію.

Один використовує різні типи сховищ під час тестування одиниць, інший використовує локальні (прямо в БД), віддалені (WCF) та тестування сховищ.

Обидва проекти можуть змінювати свої типи сховищ за допомогою коду чи конфігурації та базується на метаданих MEF / типів Lazy.

На сьогодні обидва проекти працюють неймовірно добре.