方案設計：

從上而下介紹方案，依次為：

1.框架架構圖。

2.介紹框架能做什麽，開發者能做什麽，怎麽用。

3.介紹各個模塊功能，及模塊之間的關系。

4.模塊具體實現，可以是偽代碼。

註意：1.框架與業務無關，考慮重用和擴展性，常量不要使用枚舉。

2.所有的Model需要有說明，並介紹字段含義。

總體框架

總體框架決定這個系統的未來諸多方面的命運，

例如可擴展性：好的框架會預留一定程度的擴展能力，讓未知的需求將來有容身之地；可讀性：團隊不是一成不變，加上現在的跳槽率一直很高，所以框架可讀性是決定以後新人加入後上手、維護的成本，以及他的感受（誰也不想維護一個像垃圾堆一樣的代碼）；可維護性：整體結構設計要很容易理解，設計要深入，不是項目開始的時候一拍腦袋1個小時內決定了怎麽設計就按照這種方式去做，如果這樣的話你或者你的團隊終將付出代價；可復用性：好的設計能剝離出業務相關的東西，業務無關的東西、項目間通用的東西等等，是個技術積累沈澱的過程，也是自我提高的途徑。等等諸如此類特性不一一贅述了。

模塊管理：系統由各個功能模塊組成，每個模塊包括不同業務功能，將這些模塊靈活的管理我的方法是采用反射，設計一個配置文件xml或者db table都行，配置功能模塊的Show menugroup、icon、Initialize，系統啟動時統一加載，如果未來像換個實現方式也不需要更新所有程序，只需要修改配置文件，替換功能對應的dll即可，或者改下菜單圖標、名稱等等。

容器：這麽多模塊來回切換，需要一個容器來裝載，根據項目需求可以是single docment也可以是multiple docment，這些統一交給容器來初始化、緩存、切換顯示等。容器與模塊是松耦合的，如果覺得容器設計不好看，可以單獨換掉容器部分，其他部分不用變。

組件管理

我這裏把模塊和組件分開來說，是根據模塊是功能性的，與業務相關的，組件應該是包括模塊的，有功能性組件，有非功能性組件，例如一些通用Util類等。

• 我在框架搭建的時候，一般要求具有一個Common目錄，裏面包含的組件有：

DataAccess：數據訪問組件，包含幾個常用數據庫的provider，隨著項目的積累可以逐漸補充其他數據庫的訪問。裏面定義了常用的GetDataTable，GetDataSet、ExecuteNonQuery、Transcation、ExecuteReader等常用操作。

Config：配置組件，一個系統難免有一些配置文件，通過通用的配置組件來讀取、訪問他們、可以寫一個泛型類即可解決，技術簡單但思路很清晰很好用，個人覺得。

Log：日誌組件，很多人用log4net都行，我一般是自己寫的，也沒多少代碼，但用起來順手。

Util：工具組件，定義一些常用的並且通用的xml序列化、反序列化、壓縮、讀取excel、文件操作、directory操作等等，也是個隨著自己經歷的項目越多逐漸補充積累的組件。

Control：控件組件，一般項目都有固定的界面組件庫，可以基於公司常用的庫，根據業務特性做一些展示上的封裝，一般的功能可以就直接拿來用了，界面統一、速度快、省事省力，例如我們以前表格、趨勢圖、柱狀圖、儀表盤展示很多，封成組件後只需要給一個DataSource就可以了。

DataType：數據類型，為通用組件服務的一些數據結構和類型。

• 除了通用的組件外，還有就是業務方面的，一般我建一個Modules目錄，裏面包括：

模塊裏的通用部分，我叫它InternalCommon，包括：

Entity：模塊數據結構

DataMapper：模塊的一些數據訪問封裝，有些查詢類的可以不封裝，管理編輯系統的數據訪問方式有限可以做封裝。

模塊中部分模塊共用的一些InternalUtil、InternalControl、InternalService等等

模塊本身部分：直接叫Modules，根據業務需求分成不同的模塊，劃分的依據一般根據業務相關性，相關性大的放在一個模塊裏，便於管理和閱讀、將來修改某個功能只需要替換某個功能模塊dll即可。

組件通信

通信一般我們會想到事件event，這種兩個組件或者窗體間的通信是緊耦合的，一般模塊內部會使用，但模塊與模塊之間的通信一般采用事件聚合器來做，

事件聚合器的有點是松耦合的，所有的消息管理都有聚合器本身去做，你只需要在發消息的模塊中Publish消息，在收消息的地方Subscribe消息，給一個約定好的ID以及封裝數據的結構即可。但也要慎用，用得太多到時候跟蹤調試的時候比較麻煩，所以我的原則是模塊級別的消息用它來做，普通的消息還是用.net的event來完成。

數據訪問

見組件管理裏對應部分

配置管理

見組件管理裏對應部分

日誌管理

見組件管理裏對應部分

角色權限

這也是一個系統不可或缺的部分，比較重用的做法是建立角色與用戶：

角色擁有權限，然後設置角色與用戶的對應管理，每個用戶對應有一個或多個角色，每個角色可分配給多個用戶，一種m:n的關系

有些系統會涉及到按鈕級別的權限，個人覺得這種不是太多，如果有的話可以在角色下設置功能節點，功能節點下設置按鈕節點，對其進行權限設計。

多語言化

當時我做的有些項目會買到海外，所以涉及到了一些多語言的東西，不過當時設計方案很一般，有沒有可借鑒的價值請自己衡量 呵呵。

最外層有一個多語言的配置，用於系統最常用的OK 、Cancle、Commit、Update等等，因為一個系統這類型的按鈕基本上會這麽叫，所以沒必要重復定義。

但也有一些不這麽叫的那就用功能自身的多語言配置文件，每個功能模塊對應一個自己的配置，如果想覆蓋最外層的配置，直接新增一個即可。

還有一些情況，比如表格內的字段名稱，圖的xy軸顯示等可單獨提出來一個節點，方便維護，也避免表內、圖內的文字與表外圖外的沖突。

系統緩存

當然系統緩存也少不了，不過實現起來也很簡單。定義一些全局對象，用於存放系統級的數據和配置，需要時不用再請求數據庫等。

框架設計