MEF (Managed Extensibility Framework) срещу IoC/DI

Основната цел на MEF е разширяемостта; да служи като рамка на „добавка“, когато авторът на приложението и авторът на добавката (разширение) са различни и нямат специални познания един за друг извън публикуван интерфейс ( договор) библиотека.

Друго проблемно пространство, адресирано от MEF, което е различно от обичайните IoC заподозрени, и една от силните страни на MEF е откриването на [разширение]. Има много, добре, разширими механизми за откриване, които работят с метаданни, които можете да свържете с разширения. От сайта на MEF CodePlex:

„MEF позволява маркиране на разширения с допълнителни метаданни, което улеснява богатите заявки и филтриране“

В съчетание със способността за забавяне на зареждането на маркирани разширения, възможността за запитване на метаданни за разширението преди зареждането отваря вратата към множество интересни сценарии и значително позволява възможности като [plug-in] версия.

MEF също има „Договорни адаптери“, които позволяват разширенията да бъдат „адаптирани“ или „трансформирани“ (от тип > към тип) с пълен контрол върху детайлите на тези трансформации. Договорните адаптери отварят друг творчески фронт по отношение на това какво означава и включва „откриване“.

Отново „намерението“ на MEF е тясно фокусирано върху разширяемостта на анонимни добавки, нещо, което много го отличава от другите IoC контейнери. Така че докато MEF може да се използва за композиция, това е просто малка пресечна точка на неговите възможности спрямо други IoC, с които подозирам, че ще видим много кръвосмесителни взаимодействия в бъдеще.

IoC контейнерите се фокусират върху онези неща, които знаете, т.е. знам, че ще използвам един регистратор в Unit Test и друг регистратор в моето приложение. MEF се фокусира върху онези неща, които вие не правите, има от 1 до n регистратора, който може да се появи в моята система.

Скот Хензелман и аз разгледахме тази тема по-подробно в последните hanselminutes.

http://www.hanselminutes.com/default.aspx?showID=166