1. 前言
標題只是唬人的嘿嘿，不過使用到的技術倒是很潮哈： SharpDevelop4.0 AddInTree部分（插件式架構就靠它了）， CSLA.NET, Caliburn.Mirco（MVVM）, DevExpress控件組。好吧，這個拿到優秀畢設，我承認都是靠這些惡心的技術和裝B的界面亮瞎了評審的X眼。
不多說直接上代碼？嘔，不直接上論文。
代碼有興趣直接上：http://kingmon.codeplex.com/下（十幾M太大上傳不來），如果你想入門SD4.0，CSLA.NET,Caliburn的話，可以略微參考下。
2. 界面
先來點界面解解渴：
黑窗口啟動，更快更高更強，更裝B。
Ribbon界面，Office2010風格，更炫更裝。
插件，這是亮點啊。
這個，那個樣式，我承認我使用win98的。。。。
任務管理插件
項目結構
3. 論文
摘 要： Agnes個人軟件平台是一個采用了插件式架構，提供了統一的數據呈現接口，數據處理接口和數據存儲接口，方便其他開發者進行插件開發的個人應用平台。它的插件內核是基於SharpDevelop 4.0插件樹內核的基礎上進行裁剪修改，界面框架采用了.Net最新界面呈現技術WPF。同時為插件開發者也研發了一套基於WPF三層架構MVVM，融合了Caliburn.Micro框架(VM層)，CSLA.Net框架（Model層）的統一的插件開發框架。讓插件開發者更加關注業務邏輯，而不用在插件架構和界面布局上花費太多的精力。
關鍵詞： 插件式架構；MVVM；WPF；數據接口；插件開發框架；CSLA；Caliburn；
一、引言
……此處省略幾千廢話
本系統提出的意義
本系統的插件內核是基於SharpDevelop4.0插件內核改制而來，SharpDevelop是國外著名的開源C# IDE編譯器。目前國外有很多資料關於研究SharpDevelop的插件樹內核，但是使用其內核開發出的插件式系統卻沒有，本系統就是利用了SharpDevelop的插件樹內核，重新開發了一套插件機制。同時也將代碼發放到微軟開源平台Codeplex上。為其他開發人員提供了一個應用SharpDevelop插件內核開發系統的例子。
本系統不僅僅只是應用了SharpDevelop插件樹，同時也采用了微軟最新的界面技術WPF，並且采用了目前最為流行的MVVM架構進行開發。本系統在MVVM架構上，則采用了2大開源框架：Caliburn.Micro和CSLA.Net。所以整個系統的架構與設計上也為其他開發者提供了一個很好的借鑒作用。
本系統的開發目標
開發出一個支持插件操作，界面友好，插件開發方式簡單，容易理解的插件式平台。
二、可行性分析
（一）系統初始化流程
圖2.1 系統初始化流程圖
Figure 2.1 System initialization flowchart
關於系統初始化流程圖的說明：
平台從啟動開始，首先會進行注冊表項檢測，如果注冊表中沒有關聯平台解決方案程序，那么進行修復注冊表項。
接着啟動平台內的插件服務進行加載，搜索在安裝目錄下的AddIns文件夾，將含有.addin配置文件和.dll文件一起加載進系統，讀取.addin文件的插件配置和插件信息。如果插件配置中指定了需要隨平台啟動的接口，則會根據插件配置提供的代碼入口信息執行插件啟動代碼。
在執行完插件加載和初始化后，則會根據啟動程序時候是否含有命令參數，如果含有命令參數，則判斷該參數是否是完整的解決方案路徑，如果是則加載解決方案。（該步驟實際上是用戶點擊了解決方案圖標后，則會通過執行含有命令參數的啟動平台命令）
在接下來就是初始化平台界面上的工具欄服務和工作區服務，並且加載插件配置文件中含有工作區配置的代碼。
（二）系統執行流程與數據流程
圖2.2. 系統執行流程
Figure 2.2. system implementation process
在上一步系統初始化后，便等待用戶加載解決方案，當用戶選擇了加載解決方案，系統將會通知各個插件去讀取解決方案中的數據，在用戶完成操作后，關閉系統時，系統也會通知各個插件解決方案即將關閉，各個插件進行用戶數據的保存，系統在插件保存完數據后，將解決方案保存關閉，等待用戶下一步操作。此時用戶可以選擇重新加載解決方案，或者關閉系統。這整個過程和Office系列的軟件差不多。
三、需求分析
（一）系統需求規定
1. 用例圖
本系統分析采用面向對象分析與設計，下面分別為本系統的2種用戶插件開發者和最終用戶分別編寫了需求用例，如下圖所示：
圖3.1. 面向最終用戶用例圖
Figure 3.1. face final user case diagram
圖3.2. 面向插件開發者用例圖
Figure 3.2. the plugin developers use case diagram
2. 用例描述
平台除了提供數據存儲服務之外，還提供了
1. 日志服務：插件開發者還能夠利用平台提供的日志服務，進行異常信息管理。
2. 插件服務：插件開發者可以通過定義插件擴展接口擴展自己的插件功能。
3. 實體層服務： 插件開發者也可利用實體層服務來方便地進行MVVM開發。
4. 界面服務：插件開發者可以通過系統提供的界面接口，將自己開發的控件掛接到平台主界面上。
四、概要設計
（一）系統頂級包圖設計
圖4.1 系統包圖
Figiure 4.1 system package diagram
關於各個包的說明：
1. ICSharpCode.Core：這個包是基於SharpDevelop4.0的內核而改造，主要提供插件樹加載，維護。
2. Agnes.Core：這個包是整個平台的核心，它封裝了ICSharpCode.Core,
提供更加方便的插件樹操作。同時也提供了：屬性服務，日志服務，解決方案服務等平台基礎服務。也提供了基於MVVM插件開發框架的基類。
3. Agnes.Startup：這個主要調用Agnes.Core包的服務，提供了啟動操作，維護注冊表文件關聯等功能。
4. Agnes.Mainframe：這個主要封裝了DevExpress中的控件，為插件提供了整個平台界面功能擴展。
（二）Agnes.Core詳細數據結構設計
圖4.2 Agnes.Core包圖
Figure 4.2 the Agnes.Core package diagram
關於每個類的詳細說明：
1. AgnesServiceManager：該類整合了平台所有的服務，插件只要調用該類即可獲取關於任意一個服務的信息或者調用任務一個服務。主要包含了：PropertyService（屬性服務），WorkBenchService（工作區服務），SlnService（解決方案服務），LogService（日志服務）等。
2. AgnesWorkBenchService：該服務主要是提供了插件與平台界面框架之間交互的一個接口。
3. AgnesSlnService：是一個打開，關閉，新建，管理解決方案的服務。
4. LogService：該服務負責日志管理與保存，插件可以調用該服務進行日志輸出。
5. IDocumentPanel：是界面框架的文檔界面部分的接口，插件想要在界面框架上添加一個文檔視圖，首先要提供一個實現了該接口的類，然后通過AgnesWorkBenchSerivce將該文檔視圖顯示到界面上。
6. IWorkBenchPad：是界面框架的左側信息界面部分的接口，插件想要在界面框架上添加一個信息視圖，首先要提供一個實現了該接口的類，然后通過AgnesWorkBenchSerivce將該文檔視圖顯示到界面上。
7. AgnesSln：是存儲解決方案的實體類
8. ScreenBase：是封裝了ViewModel框架Caliburn.Micro的基類
9. ModelBase：是封裝了Model框架Csla.Net的基類
（三）Agnes.Mainframe的數據結構詳細設計
圖4.3 Agnes.Mainframe 包圖
Figure 4.3 the Agnes.Mainframe package diagram
關於每個類的詳細說明：
1. MainWindow：整個程序的WPF主窗口。
2. MainframeView：承載了整個DxRibbon框架的視圖，是整個平台的主界面。
3. MainframeViewModel：是MainframeView的ViewModel，主要提供數據源，它將調用Agnes.Core的WorkBenchService，讀取WorkBenchService的IWorkBenchPad和IDocumentPanel數據綁定到MainframeView界面上。
4. NewSlnView和NewSlnViewModel：是關於新建解決方案的界面和數據操作。
5. OpenSlnView和OpenSlnViewModel：是打開解決方案的界面和數據操作。
五、詳細設計
（一）程序系統的結構
圖5.1 程序結構圖
Fig 5.1 the program structure diagram
（二）程序模塊設計說明
1、 插件樹
（1）模塊描述
插件樹是整個Agnes平台實現插件機制的核心部分，它取之於SharpDevelop4.0[1]，並在其上進行修改。
（2）模塊功能
插件樹為整個平台提供了插件搜索，插件加載，插件接口管理等功能。
（3） 模塊流程邏輯
用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。
（4） 模塊設計
圖5.2 AddInTreeNode 類圖
Figure 5.2 AddInTreeNode class diagram
詳細說明：AddInTreeNode代表了一個插件樹上的一個擴展節點，它是從.addin配置文件中生成而來，通過它的BuildChildItem函數可以獲取到插件上的對象。這是系統調用插件的主要方式。
圖 5.3 AddInTree 類圖
Figure 5.3 AddInTree class diagram
詳細說明：AddInTree代表了整棵插件樹，它是由AddInTreeNode組成。通過InsertAddIns，RemoveAddIn可以對整個插件樹進行增刪改操作。
圖5.4 AddInManager 類圖
Figure 5.4 AddInManager class diagram
詳細說明：AddInManager是插件管理器，他主要封裝了插件樹的操作。它的主要作用是從插件配置文件中，讀取插件配置，並且插入到插件樹中。
（5） 模塊接口
在上層模塊Agnes.Core的初始化過程中（參考圖1.），搜索插件則是調用該模塊進行插件加載。
2、解決方案模塊
（1）模塊描述
解決方案是整個平台和所有插件用戶數據存儲的地方，它實際上是一個壓縮包，在壓縮包中，每個插件都擁有一個數據存儲的文件夾。這個模塊主要是描述解決方案實體類，和提供打包和解包解決方案的方法。
（2）模塊功能
1. 描述了解決方案的基本信息
2. 提供壓縮和解壓解決方案。
（3）模塊設計
圖 5.5 AgnesSln 類圖
Figure 5.5 AgnesSln class diagram
詳細說明：它是一個使用了Csla.Net實體框架的實體類。
1. 每個解決方案都會有一個TempDir的屬性，這個屬性是指解決方案在打開之后，被解壓到的臨時文件夾。
2. Package和UnPackage：Package函數將會根據TempDir指定的臨時文件夾重新壓縮成一個解決方案，而UnPackage則是相反。需要注意的是：UnPackage如果需要密碼，則會解壓失敗。除非在Unpackage解壓的時候傳入所需要的密碼。
3. 其他屬性說明：
FullName：解決方案完整的存放路徑加文件名
LocatedDir：解決方案存放路徑
SlnName：解決方案名稱
圖5.6 AgnesSlnService 類圖
Figure 5.6 AgnesSlnService class diagram
詳細說明：AgnesSlnService是封裝了AgnesSln的操作的一個靜態類，它主要管理當前程序運行環境中使用的解決方案。
1. 通過CurrentSln可以獲取當前環境中打開的解決方案，如果沒有則為NULL
2. 插件通過將事件掛接到SlnCloesdHandler或者掛接到SlnOpenedHandler上，即可在用戶打開或者關閉解決方案的時候獲得通知。
3. 外部也可以通過OpenSln或者CloseAndSaveCurrentSln打開或者關閉保存解決方案。
3、界面框架模塊
（1）模塊描述
界面框架模塊主要是提供給插件關於在界面框架中插入插件所需的視圖的接口。
（2）模塊功能
1. 讀取插件配置中關於插件需要在框架中顯示視圖的代碼。
2. 提供給外部如何在框架中添加視圖的接口
（3） 模塊設計
A. 界面框架說明：
整個界面框架采用了WPF界面開發技術[2]，主界面如下圖所示：
圖 5.7 界面說明
Fig 5.7 interface description
如圖所示：界面框架分為3個區域：WorkBenchPad，ToolPad，DocumentPanel。
a) WorkBenchPad：該區域是作為一些概覽信息的展示，插件如果想在這一塊區域添加自己的視圖，則需要在.addin配置文件中加入如下元素：
<Path name="Agnes/Workbench/WorkbenchPad">
<WorkbenchPad id="Agnes.MyDocsLib.MyDocsLibSmartTreePad"
class="Agnes.MyDocsLib.MyDocsLibSmartTreePad" />
</Path>
（1） 該元素name是：Agnes/Workbench/WorkbenchPad這樣的一個插件樹路徑
（2） 該元素的class是指向插件內部關於這個視圖的一個類。這個類必須實現IWorkBenchPad接口。
b) ToolPad：該區域作為插件工具欄顯示，插件如果想在界面框架的工具欄上添加入自己的工具欄，則需要在.addin添加如以下元素：
<Path name="Agnes/Mainframe/ToolPad">
<ToolPad id="Agnes.MyDocsLib.ToolPad"
PadStyle="Other/ToolPad/MyDocsLibToolPad.xaml"
BarItemsKey="MyDocsLibBarItems"
RibbonPageKey="MyDocsLibRibbonPage"
/>
</Path>
（1） 該元素name屬性是：Agnes/Workbench/ToolPad這樣的一個插件樹路徑。
（2） PadStyle屬性應該是指向描述該ToolPad的XAML代碼。
（3） BarItemsKey：指向XAML代碼中，哪個節包含了ToolPad的詳細布局和控件信息。
（4） RibbonPageKey：指要加入的ToolPad的頁。
c) DocumentPanel：該區域為文檔視圖。插件如果想要在用戶執行了某些操作后，在該區域中添加入一個文檔，則插件應該實現聲明一個實現了IDocumentPanel的類，並在運行時加入AgnesWorkBenchService的DocumentPanels集合中。
B. IWorkBenchPad
圖 5.8 IWorkBenchPad 類圖
Figure 5.8 IWorkBenchPad class diagram
詳細說明：這個是任何需要掛接在界面上的WorkBenchPad都需要實現的接口。
1. Content：這個屬性是整個WorkBenchPad的UserControl
2. ImageUri：這個屬性是WorkBenchPad標題前的圖標
3. IsHide：指這個WorkBenchPad是隱藏還是顯示
4. Title：指WorkBenchPad的標題
5. WorkBenchPosition：指WorkBenchPad的位置
C. IDocumentPanel
圖 5.9 IDocumentPanel類圖
Figure 5.9 IDocumentPanel class diagram
詳細說明：IDocumentPanel是任何需要在界面框架的文檔視圖集合中添加文檔視圖必須實現的接口。
1. Caption和CaptionImage：是指文檔視圖的標題和標題圖標。
2. Content：是指文檔視圖中的具體內容。
3. IsDirty: 是指文檔內容是否被用戶修改過。該屬性可用來判斷是否需要保存。
4. IsVaild：是指文檔內容被用戶修改過后是否內容填寫正確。
5. Cancel函數：關閉視圖時，不保存直接關閉
6. PreViewClose函數：是在關閉視圖前會觸發的函數，具體類可在此函數中填寫關閉視圖需要進行的操作。
7. Save函數：保存視圖
D. AgnesWorkBenchService
.
圖 5.10 AgnesWorkBenchService 類圖
Figure 5.10 AgnesWorkBenchService class diagram
詳細說明：AgnesWorkBenchService是實現這個模塊的主要類。該類包含了系統當前運行中所包含所有插件的WorkbenchPad，ToolPad，DocumentPad。並且Agnes.Mainframe模塊也會從該類中讀取各種界面信息，然后在界面上綁定出來。而插件則會通過該類將所需要展示的界面添加到相應的屬性中。它是插件與界面之間的一個重要橋梁。
關於重要屬性的說明：
1. BarItems：是指ToolPad上面的控件。
2. BottomPads、RightPads、LeftPads：其實都是WorkBenchPad只是在不同位置上的顯示而已。
3. FocusedDocumentPanel：是指目前獲得焦點的DocumentPanel
4、日志服務
（1）模塊描述
日志服務主要是利用開源的Log4Net日志記錄模塊，提供給插件或者平台出錯時記錄信息的一種方式，它主要會將日志信息呈現在兩個地方：控制台和安裝目錄下的Log文件夾下的文件。
（2）模塊功能
1. 提供插件一個輸出日志的接口
2. 將日志實時呈現到控制台窗口
3. 在系統關閉的時候將日志保存到文件中
（3）模塊設計
Log4NetService
圖 5.11 Log 類圖
Figure 5.11 Log class diagram
詳細說明：該類主要提供了日志輸出功能。外部可直接調用相應的級別輸出日志信息，級別分別為：Debug、Error、Fatal、Info、Warn 5個級別。
需要說明的一點是：Log4netLoggingService集成於AgnesServiceManager中，所以想要使用日志服務還需通過服務管理。
5、插件開發框架
（1）模塊描述
插件開發框架主要封裝了實現MVVM架構的CSLA.Net[3]和Caliburn.Micro[4]兩個開源框架的操作，方便和統一插件開發。
（2）模塊功能
1. 在插件開發框架中提供VM層的Caliburn框架的封裝基類ScreenBase。
2. 在插件開發框架中提供Model層的實體框架CSLA的封裝基類ModelBase。
（3）模塊設計
A．ScreenBase
圖 5.12 ScreenBase 類圖
Figure 5.12 ScreenBase class diagram
ScreenBase是從Caliburn中的Screen中繼承而來，封裝並簡化了其中一些操作。
關於其中一些函數的說明：
1. CreateView()：這個函數需要子類去實現，主要是返回該ViewModel對應的View的實例。
2. GetView（）：通過該函數可以根據一個Model實例找出對應的界面為UserControl的WPF View[5]。
3. OnModelChanged（）：當Model1發生變化是會觸發該函數。
4. TryClose（）：當用戶關閉或者注銷對應的View會觸發該函數。
B．ModelBase
圖 5.13 ModelBase類圖
Figure 5.13 ModelBase class diagram
ModelBase是從CSLA中的BusinessBase基類繼承而來，它主要可以管理對象狀態，進行多重撤銷，數據驗證等多種功能。
對於其中一些函數的詳細說明：
1. CreateAsChild（）：這個函數需要子類實現，子類主要在此函數中添加對象初始化的默認字段。
2. FetchAsChild（）：這個函數需要子類實現，子類主要在該函數中根據參數加載對象，參數一般是一個XElement類型。
3. 子類中應該重新編寫保存方法：SaveToXml（）將對象保存到xml中。
六、操作使用說明
1. 程序目錄說明
圖 7.3 程序目錄
Fig 7.3 the program directory
整個程序目錄如上圖所示：
A． AddIns文件夾：主要存放插件與插件配置，在它下面Mainframe文件夾中存放的是系統的界面框架插件，而在App文件夾中存放的是整個平台的應用插件。
B． Bin：程序的主目錄。
C． Data：整個平台的信息配置等文件
D． Log：存放日志文件
2. 啟動
直接運行Bin\Agnes.exe，可以看到程序從控制台開始運行，如圖所示：
圖 7.4 程序啟動控制台
Figure 7.4 program to start the console
在等待一系列的初始化之后，可以看到整個界面框架如圖所示：
圖7.5 主界面框架
Fig 7.5 Main Interface Framework
這是一整個原生態的界面框架沒有安裝任何插件，下一步我們將開始安裝插件。
4. 安裝插件
下面我們將進行文檔庫管理插件的安裝，首先將編譯好的插件庫MyDocsLib.dll和插件配置文件MyDocsLib.addins放入程序目錄的AddIns\App\MyDocsLib文件夾中。
重新啟動程序可以看到在主界面框架上，插件所添加的視圖和工具欄已經顯示出來，如下圖所示：
圖7.6 按照插件后的界面框架
. Fig. 7.6 in accordance with the plug-in interface framework
5. 解決方案管理
點擊開始按鈕進入解決方案管理，如下圖所示：
圖 7.7 開始按鈕
Fig 7.7 the start button
以下是新建解決方案的界面：
圖 7.8 新建解決方案
Figure 7.8 new solutions
輸入相關信息點擊創建解決方案即可，創建完成后，系統會自動打開解決方案，如果不需要加密，則方案加密留空即可。
需要說明的是，在平台使用過程中，如果輸入信息不符合規范則會出現驗證錯誤，按鈕被禁用的情況，如下圖所示：
圖 7.9 輸入錯誤信息后的解決方案界面
Fig 7.9 input errors after solution interface
其次，可以選擇打開頁簽打開解決方案如下圖所示：
圖 7.10 打開解決方案界面
Fig 7.10 the open solution interface
6. 日志查看
在安裝目錄的Log文件夾下有每一次運行程序的日志文件，用文本編輯器打開即可查看。如下圖所示：
圖7.11 日志文件夾
Fig 7.11 the log folder
打開其中一個文件如下圖所示：
圖 7.12 日志文件
Fig 7.12the log file
上面每一節就代表了一個日志信息，可以從中看出日志觸發時間，異常級別，一次類等信息。
七、總結與展望
本系統經歷半年多的調研，設計與編碼，最終終於完成開始制定的目標。雖然整個系統在使用上，仍然存在一些操作不便，難以理解等。在插件上，由於時間關系，仍然沒有讓整個系統對插件進行智能化管理，所以安裝和卸載插件仍然要由用戶自行根據說明書進行操作，這兩點是做的不足和需要改進的地方。
在開發過程中，也確實遇到了很多很艱難的問題，比如：SharpDevelop插件系統在國內的資料比較少，而且很多不齊全。導致在插件樹和插件機制上花了很多功夫去理解，最后只能去官方網站上下載SharpDevelop的源代碼。經過了很長一段時間的研究，最終終於能夠深刻的理解了整個插件樹的機制，並且根據自己的需求開發出了屬於自己平台的一套插件機制。其次，是對於CSLA.Net的理解。也是由於國內幾乎沒有什么人對CSLA進行研究和應用而找不到齊全的資料，導致一開始理解不准確，最后開發出來的平台關於CSLA部分發現了很多缺陷，例如數據撤銷和回滾功能，最后只能去官方網站和原作者進行交流，從而解決了這部分的問題。
對於未來的展望，目前這個系統整個架構已經成型，對於插件開發框架也已經比較成熟，在插件開發框架上，我們的組員也開發出了2個具有實際功能意義的插件。 從證實了整套開發框架和插件架構的可行性。這一個系統的架構和設計對於未來無論是商用還是其他的軟件開發，都具有很大的借鑒價值和實際意義。