先前研究過SharpDevelop,SharpDevelop采用框架——插件的可擴展的體系結構，畢竟代碼水平比較高，對它的插件開發(fā)方式沒有學習徹底。

.NET Framework 3.5 的System.Addin命名空間讓插件開發(fā)變的簡單很多了。

1.什么是AddIns

在應用程序運行期間允許動態(tài)添加程序集。

插件開發(fā)可以在給開發(fā)完成的應用程序添加功能。我們可以創(chuàng)建一個主機應用程序，隨時間的推移給它添加越來越多的功能這些功能可以是開發(fā)團隊編寫的，也可以由其他供應商也可以創(chuàng)建插件，擴展該應用程序。

2.AddIns（MAF）的設計目標如下

應用程序容易開發(fā)插件

在運行期間高效查找插件

開發(fā)主機程序應是一個很簡單的過程，但不像開發(fā)插件那么容易

插件和主機應用程序應獨立進行維護和升級

3.MAF體系結構

MAF體系結構基于一個包含7個程序集的管道。這個管道解決了插件的版本問題。因為管道中的程序集之間的依賴性很低，所以合同、主機程序和插件升級到新版本可以完全互不干擾。

其中心是合同程序集。這個程序集包含一個合同接口，其中列出了插件必須實現(xiàn)、可以由主機程序調用的方法和屬性。合同的左邊是主機端，右邊是插件端。圖中還 顯示了程序集之間的依賴性。最左端的主機程序集與合同程序集沒有依賴性，插件程序集與合同程序集也沒有依賴性，這兩個程序集都沒有實現(xiàn)合同定義的接口，只是有一個對視圖程序集的引用。主機應用程序引用主機視圖；插件引用插件視圖。視圖包含抽象的視圖類，該類定義的方法和屬性與合同相同。

下圖是上圖的中文說明：

下圖是插件開發(fā)結構類關系圖

有了這個模型，插件端和主機端可以完全獨立地升級了，只是需要使用映射層。例如，如果主機的一個新版本使用全新的方法和屬性，合同就仍可以保持不變，只有適配器需要修改。也可以定義新的合同。適配器可以修改，也可以同時使用幾個合同。

下圖顯示了MAF體系結構的外觀為一個單一的插件。如果我們要創(chuàng)造更多的插件（如演示應用程序） ，我們就必須建立新的類來繼承插件適配器來完成該功能。

4.插件模型文件夾結構

除了AddIns目錄之外，其他目錄都直接包含管道特定部分的程序集。AddIns目錄為每個插件程序集包含一個子目錄。插件也可以保存在完全獨立于其他管道組件的目錄中。

MAF需要使用反射來動態(tài)加載，才能獲得插件的所有信息。而且，對于許多插件而言，這還會增加主機應用程序的啟動時間。因此，MAF使用一個 高速緩存，來保存管道組件的信息。該高速緩存是由安裝插件的程序創(chuàng)建的，如果主機應用程序有管道目錄的寫入權限，該高速緩存就由主機應用程序創(chuàng)建。

在目錄結構中有一個PipelineSegments.store文件，它是一個外接程序，有兩個任務：

◆將有關所有外接程序和管線段的信息注冊到緩存文件中。

◆通過搜索緩存查找外接程序的指定宿主視圖的外接程序

在AddIns文件夾里面會有一個Addins.store文件，它的作用就是讓程序查找插件顯示在應用程序中。

應用插件開發(fā)對應用系統(tǒng)來講確實有很大好處，很多應用程序都使用了插件開發(fā)，例如：Visual Studio、Eclipse、還有瀏覽器IE、FF,雖然我們不是這些軟件的開發(fā)商，但是我們仍然可以在這些軟件里添加我們需要的功能，插件開發(fā)更容易維護和升級系統(tǒng)，而且對提高程序運行效率也有很大幫助。

網(wǎng)上關于Addins的示例代碼比較少，自己找了兩個，大家研究下。

【編輯推薦】

1. Visual Studio 2010截圖曝光 以WPF開發(fā)UI
2. 為WPF項目創(chuàng)建單元測試
3. 詳解Silverlight和WPF互相擴展
4. 教你如何理解WPF中的Template類
5. 詳談WPF開發(fā)中的數(shù)據(jù)虛擬化