本系列文章以  SailingEase WinForm Framework 為基礎進行設計並實現，但其中的設計理念及方法，亦適用於任何型別的客戶端應用程式的設計與開發。

目錄：

前言：

可能是接觸計算機比較早，從96年左右386開始，到 Trubo C，以及後來的Foxpro、VB、Delphi，一直以來似乎都有一種客戶端程式情節，喜歡寫客戶端程式。

在 .Net 出現以後，投入了許多時間在研究 .Net 程式設計上，在客戶端領域早年基本以 WinForm 為主，近幾年逐漸轉向了 WPF。

除了日常工作中的專案開發，業餘時間使用 WinForm 寫過許多東西，比較成型的大概有兩個

1）SailingEase WinForm Designer IDE （2007~2010 暫停開發）

    高度實現的 IDE 開發環境，完整實現了 WinForm Designer，可通過視覺化配置的方法，定義介面和業務邏輯，並使用 XML 進行描述。

    這個專案一開始的設想，心很大，企圖做一個讓不懂程式設計的人，也能拖拖畫畫加上配置，來生成企業所需的管理軟體。投入了大概兩年多的業餘時間，這期間應該是我自己開發能力和設計能力增漲最快的時期，開始做這個專案的時候，有太多的問題超出能力範圍，只好到處找書看、找資料學習。在每天回家的路上看完了《設計模式》，平時的碎片時間看完了《程式碼大全2》，另外閱讀了 SharpDevelop 的許多原始碼，也有一部分的實現是參考了它的思路和程式碼。

   2010年左右由於時間和精力有限，加上對於軟體專案有了一些新的認識和想法，這個專案就暫停至今。其它幾個小規模的 WinForm 專案，和本系列文章的主角：SailingEase WinForm Framework，均脫胎於此專案。

2）SailingEase .NET Resources Tool

　　一款輔助多國語言軟體開發的實用工具，目的在於通過生成介面來約束不同語言資源的實現，使開發人員可以基於介面呼叫資源。 此外，提供方便開發人員使用的各種實用功能，如多專案並行編輯，資源匯入，Excel 匯入、匯出等。

　　這個專案源自於上面的 IDE 專案，由於做 IDE 時心太大，希望能夠支援多國語言，但是慢慢發現從工程角度來說，這是一件非常麻煩，容易不可控的事情。就花了結時間，想了一個辦法，用介面來約束不同的資源。

最後祭出本系列文章的主角：SailingEase WinForm Framework。

其實這是從 IDE 專案中提取出來的一個純開發框架，它沒有使用者管理、許可權管理之類的現成功能，而是提供純開發角度的開發框架，概括來說提供了以下幾方面的功能：

      a.宿主程式（殼）與功能模組（外掛）的載入、排程、通訊等實現；

     b.不同外掛之間在完全接耦合的基礎上，同步/非同步呼叫、狀態響應等機制的實現；

     c.外掛之間在程式碼層面完全沒有互相引用關係，可以實現在缺少任意外掛的情況下啟動應用，即使他們在UI層有交集；

     d.支援模組間的依存關係定義；

     d.事件聚合器，用於在完全解耦的條件下，釋出及訂閱事件；

     d.宿主程式提供了統一的主選單及右鍵選單的註冊/吊銷/狀態控制機制；

     e.宿主程式提供了統一的視窗排程/載入/銷燬功能；

     f.宿主程式提供了統一的日誌記錄、異常捕獲，Web頁面互操作等功能；

     g.基於 GDI+ 自行實現的控制元件包，提供了高度的可擴充套件性；

     h.基於zip格式的檔案包管理器（基於zip的自定義檔案格式，讀取或寫入指定的流）；

     i.對http、xml、磁碟io、反射、加解密等操作的增強與封裝； 

     j.其它……

第一章節：客戶端軟體的架構設計概述

    本章節將概述基於 SailingEase Winform Framework 框架的客戶端應用程式的架構設計。

    時常有朋友或者客戶會問：“你這個軟體是不是三層架構設計”。

    實際上客戶端軟體的架構並不是這麼劃分設計的，也遠遠比所謂的三層架構要複雜的多，與 Web 程式在不同的頁面間無狀態跳轉不同，客戶端程式更加成一個整體，單頁面 Web 應用有一些方面與之類似，不過亦有許多不同。

    我們通過一個簡單的設計圖初步瞭解基於 SailingEase Winform Framework 的客戶端程式架構：

      SailingEase WinForm Framework 的核心，就是模組化。

      基於 SailingEase WinForm Framework 框架的應用程式由執行時動態載入的鬆散耦合模組組成，模組包含代表系統不同功能的可視和非可視元件，可視元件（檢視）被組合在一個外殼中（主視窗）。

      宿主程式提供各種基礎服務，並將這些模組級元件結合在一起；模組也可以提供與應用程式的特定功能相關的其他服務。

      SailingEase Winform Framework 是“複合檢視”設計模式的實現，此模式支援包含子項的檢視遞迴結構。這些子項本身也是檢視，這些檢視通過某種機制組合起來（在執行時動態組合而非設計時靜態組合）。

      模組永遠不會相互直接引用，也不會直接引用宿主。它們會利用服務、事件聚合等機制在彼此之間以及宿主之間進行通訊，並響應使用者操作。

      使用模組來組成系統有很多好處。模組可聚合來自同一應用程式中不同後端系統的資料。此外，系統可隨著時間的推移更加方便地發展演變。在系統需求發生變化而需要向系統中新增新模組時，與非模組化系統相比，模組化系統面臨的衝突要少很多。而且還可以對現有模組進行獨立性更強的改進，從而改善可測試性。

      模組可由不同的團隊開發、測試和維護。在小團隊開發維護模組時，也不必載入編譯整個應用程式解決方案，只需建立一個包含宿主和指定模組的精簡解決方案即可。

      在 SailingEase Winform Framework 中，可定義不同模組間的動態依存關係，有時一個完整的業務操作需要不同模組間協作完成，而其中有些環節不是必須的，此時我們可在缺失部分模組的情況下，正常執行完整個業務流程：

      主動模式：

      主動模式使用建造者模式進行實現，由業務或操作的發起模組主動控制流程，由其自身判斷需要響應的模組和模組是否存在。

      被動模式：

      被動模式使用事件聚合器進行實現，業務或操作的發起模組完成自身操作後，向事件聚合器傳送通知，在事件聚合器中註冊過的模組會收到相應的通知和資料，從而響應業務操作，響應事件聚合器的不同模組可使用多執行緒技術併發處理。

      在被動模式中，事件的釋出模組，完全不關心有哪些模組會響應事件，也不關心事件的響應結果。對於響應事件的模組來說，它們也不關心事件是由誰釋出的，只需處理好相應的業務即可。

      檢視級別的動態依存：

      舉例來說，當我在使用者資訊模組中的使用者列表畫面中選擇使用者時，畫面底部需要顯示使用者最近一筆訂單，而這個訂單資訊區域（View），需要由訂單模組提供，但是當訂單模組不存在，或沒有載入時，使用者畫面依然可以正常顯示及使用，只是顯示訂單資訊的位置，被隱藏了。

      當用戶模組和訂單模組同時存在時：

　　選中使用者列表中的使用者，則在畫面下方自動顯示其最近訂單。

      顯然使用者模組與訂單模組不僅有檢視層面的融合，還有操作響應上的融合，而這些融合與呼叫，在 SailingEase Winform Framework 中是完全解耦合的，兩個模組之間不存在任何互相引用關係。

       當訂單模組不存在或沒有載入時，使用者模組中的畫面將自動調整，UI操作不會有任何影響：

 模組化只是基礎，除了模組化之外，作為宿主程式，通常會提供一系列的基本功能實現。

    其中特別重要的有幾點：主選單/右鍵選單/工具欄的融合與排程，視窗排程器、執行緒排程器、服務容器、事件聚合等等，我將在後續的文章中詳細闡述。

      一個典型的基於 SailingEase Winform Framework 的應用程式架構

     以 SailingEase WinForm Designer IDE 為例：

       執行時效果：

       在下一章節中，我將對客戶端應用程式的架構作更進一步的闡述，並詳細說明基於 SailingEase Winform Framework 的模組化開發如何實現。

      歡迎加我QQ交流探討，共同學習：279060597，另外我在南京，有南京的朋友嗎？