MEF的全稱是Managed Extensibility Framework（MEF），其是.net4.0的組成部分，在3.5上也可以使用。熟悉java中的spring架構的人，對這個架構中涉及的幾個概念應該會比較容易了解。
這裡我先把我兩年多前的一個完整的利用MEF搭建的插件式系統中涉及到的MEF架構裡的幾個基本概念大緻描述下。
MEF架構中提供 import和export功能，即注入和導出。Spring中有依賴注入這個概念，這裡的這個概念也是大同小異，即将某個對象執行個體化後，注入到依賴這個執行個體的對象中，如此可以降低類之間的耦合。同樣，與spring中的注入類似，MEF也有延遲注入這個概念，普通的依賴注入在整個程式開始運作時便進行了注入，而這種延遲注入可以做到隻有當對象需要被使用時才進行注入。
約定是與依賴注入相輔相成的。依賴注入最大的好處就是類與類之間解耦，但是如何知道到底是将一個類注入到另外一個類中呢，這裡就需要約定這個概念了。既需要注入的類并不用直接引用對方的類，而是兩者通過一個共同的接口（也可以是類等其他），此接口即為約定，進而進行導出和注入。
我們用spring時，針對不同的應用，我們隻需要啟動applicationContext或者WebApplicationContext将配置加載到IOC容器中，根據XML配置或者注記便可以實作類的依賴注入。在MEF架構中，這種IOC容器需要代碼來進行實作，并且配置一般通過注記的方式。
這裡涉及到兩個概念，分别是catalog和compositionContainer。catalog中将所有需要組裝到IOC容器中的類集中到一起，然後再将catalog放入到componentContainer中，這樣我們的IOC容器便擁有了所有的需要進行控制的類。但是僅僅放入後，也并不能讓容器進行自動的依賴注入，它還需要我們進行ComposeExportedValue和SatisfyImportsOnce這樣的操作，才能真正的完成依賴注入的全過程。
我這裡先把兩年前的那個項目的内容大緻描述下。該項目為一個影像處理全自動化的項目，分為影像的自動化接收，利用Platform進行并行化預處理，然後再利用此平台對影像進行冰淩、幹旱、洪澇的分析處理，最後生成産品後釋出和入庫。當時是由幾個大學和一個機關一起合作完成的，哪幾個大學就不說了。我隻是這些衆多參與人中的一個，不過我不是像他們做遙感用envi的DLL語言處理影像的，也不是他們用Platform做并行計算的，也不是那些背景做産品釋出和入庫的。我做的主要是下面這個需求。
（1）将每天接受的原始影像展現在前台，盡量以合理的美觀的方式展現。
（2）提供影像的查詢功能，包括時間空間等查詢。
（3）提供影像的下載下傳功能。
（4）提供日志的查詢功能。
（5）提供對伺服器的監聽功能。
（6）将手動處理完的成果進行管理和展示。
（7）提供對手動處理完的資料進行中繼資料注冊。
（8）能将自動化中的各個子產品提煉成手動也能輔助進行的子產品，并且可以內建到系統中。
看了需求後，我第一個感覺就是這個系統得做出插件式系統，最後我標明了MEF。既然決定了要做插件式系統，那麼就得把需求分一個類，及哪些是宿主程式本身有的，哪些是該做成插件。顯而易見，需求中的（1）到（6）都可以做在宿主程式中。而（7）和（8）的話，都是單獨的插件子產品，因為這（7）和（8）的功能都是提取自自動化流程中的，由各個不同的人員完成，我這裡隻需要提供他們統一的接口以及需要的調用方式就可以由他們自身做成插件了。而且以後可能會将更多的自動化流程提取出來，都做成插件後，友善擴充。
這裡主要講針對插件系統的技術需求。
（1）能夠将插件插入到相應的地方，比如是工具欄呢還是左側選擇欄等。
（2）點選插件所在的按鈕後，插件能彈出。這裡需要的是單例模式。
（3）插件能和宿主通訊，比如插件完成了某項功能，需要通知宿主該功能已經完成。
（4）插件和插件之間也要能通訊，比如一個插件完成了某個功能後，能将得出的參數顯示在另外一個插件上。
下一節，插件架構的通信機制的實作中，我會首先講下這個架構實作中的核心部分。在下下講中我們再講整個架構的依賴注入和界面實作。
如果您覺得本文确實幫助了您，可以微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^