Managed Extensibility Framework：它是什么，前景如何
顧名思義，Managed Extensibility Framework 是一個用來擴展 .NET 應用程序的框架。最近 Channel 9 采訪了 Oleg Lvovitch 和 Kevin Ransom，談到 MEF 的歷史以及第二版的計劃。
MEF 非常不幸地成為 .NET 里最常被誤用的庫。開發者經常把它用作一個通用的依賴注入框架或者控制反轉容器，這些角色都不適合它。甚至有人更進一步地把它用作“new”運算符的替代品。微軟的 Glenn Block 解釋了 Managed Extensibility Framework 的真正用意：
我們不希望把 MEF 看作通用 IoC。最好把 MEF 的 IoC 方面看作一個實現細節。我們使用 IoC 模式是因為它很好地解決了我們面臨的問題。
MEF 的關注點是擴展性。當你考慮 MEF 時，把它看作推進我們的平臺發展的一項投資。我們將來的產品和平臺將會把 MEF 用作添加擴展性的標準機制。第三方產品和框架也將利用相同的機制。MEF 的普通“用戶”會創建 MEF 可以使用的組件，但不會在他們的應用程序里直接使用 MEF。
想象一下，當你想擴展我們的平臺時，你在 bin 文件夾里放一個 dll，你的事情已經完成了。啟用 MEF 的應用程序會識別并利用新的擴展。這才是 MEF 的愿景。
到目前為止，MEF 的歷史上最重要的應用程序是 Visual Studio 10。許多特性都是為了滿足 Visual Studio 里的編輯器的需求，比如說，延遲加載所有東西和細粒度協定。隨著托管代碼慢慢地取代基于 COM 的擴展模型，在 Visual Studio 里使用 MEF 的情況在 Visual Studio 11 里會逐漸增加。
MEF 2.0 不會是一個革命性的版本。大多數特性都是為了解決 Visual Studio 組和廣大社區反饋的問題。一個重要的改變是簡化了編程模型。雖然適合像 Visual Studio 的復雜應用程序，但承載 API 對于只有少數幾個擴展點的小型應用程序來說有點復雜。這項工作仍然在進行中，目前沒有細節可以提供。
另一方面，MEF 正在嘗試更好地支持容器的層級結構。每個容器都可以把它自己的上下文添加到從父容器繼承過來的上下文。舉個例子，Visual Studio Shell 可以看作一個容器。里面包含了每個項目的容器，對應的上下文包含了項目類型和項目文件等信息。第三層容器可能是單個文件的編輯器。MEF 1 已經可以處理這種情況，不過做法有點笨拙。
MEF 1 的一個主要問題是無法診斷組合問題。沒有 MEF 的源代碼和巧妙設置的斷點，要確定具體的原因可能非常困難。MEF 2 在這方面已經投入大量資源，確保這將不再是問題。
.NET 4.5 的一個新特性是自定義反射上下文。你可以根據常規 C# 代碼的表達規則在運行時通過反射上下文向一個類添加特性聲明。MEF 2 里的 RegistrationBuilder 會接受這些自定義特性，把它們當作本來就有那樣處理。這允許在 MEF 里使用 POCO 類型，即使你無法訪問這些類型的源代碼。
MEF 也將適用于 Windows 8 Metro 應用程序，但形式上會有很大不同。大多數高級功能都被移除，只關注 MEF 的主要用途，暴露擴展點和加載擴展。
來自: InfoQ
查看英文原文：Managed Extensibility Framework: What It is and Where It is Going