框架設計總結

前言

畢業7年多時間，GIS出身的我從畢業就開始走上了編程的道路，接觸過c++、java、.net,不過最終.net成了我營生的工具。

7年終準確地說待過3家公司，純作GIS軟件的，一家作電信運營商軟件的，如今這家作民航業務的，這3家公司有個共同點就是CS爲主，偶爾冒出一個兩個的BS小項目技術上也就是練練手入個門而已，因此始終對CS的框架比較關注，本身想作個總結，歡迎你們補充和指正。

整體框架

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

例如可擴展性：好的框架會預留必定程度的擴展能力，讓未知的需求未來有容身之地；可讀性：團隊不是一成不變，加上如今的跳槽率一直很高，因此框架可讀性是決定之後新人加入後上手、維護的成本，以及他的感覺（誰也不想維護一個像垃圾堆同樣的代碼）；可維護性：總體結構設計要很容易理解，設計要深刻，不是項目開始的時候一拍腦殼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：控件組件，通常項目都有固定的界面組件庫，能夠基於公司經常使用的庫，根據業務特性作一些展現上的封裝，通常的功能能夠就直接拿來用了，界面統1、速度快、省事省力，例如咱們之前表格、趨勢圖、柱狀圖、儀表盤展現不少，封成組件後只須要給一個DataSource就能夠了。

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

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

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

Entity：模塊數據結構

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

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

模塊自己部分：直接叫Modules，根據業務需求分紅不一樣的模塊，劃分的依據通常根據業務相關性，相關性大的放在一個模塊裏，便於管理和閱讀、未來修改某個功能只須要替換某個功能模塊dll便可。

組件通訊

通訊通常咱們會想到事件event，這種兩個組件或者窗體間的通訊是緊耦合的，通常模塊內部會使用，但模塊與模塊之間的通訊通常採用事件聚合器來作，

事件聚合器的有點是鬆耦合的，全部的消息管理都有聚合器自己去作，你只須要在發消息的模塊中Publish消息，在收消息的地方Subscribe消息，給一個約定好的ID以及封裝數據的結構便可。但也要慎用，用得太多到時候跟蹤調試的時候比較麻煩，因此個人原則是模塊級別的消息用它來作，普通的消息仍是用.net的event來完成。

數據訪問

見組件管理裏對應部分

配置管理

見組件管理裏對應部分

日誌管理

見組件管理裏對應部分

角色權限

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

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

有些系統會涉及到按鈕級別的權限，我的以爲這種不是太多，若是有的話能夠在角色下設置功能節點，功能節點下設置按鈕節點，對其進行權限設計。

多語言化

當時我作的有些項目會買到海外，因此涉及到了一些多語言的東西，不過當時設計方案很通常，有沒有可借鑑的價值請本身衡量 呵呵。

最外層有一個多語言的配置，用於系統最經常使用的OK 、Cancle、Commit、Update等等，由於一個系統這類型的按鈕基本上會這麼叫，因此不必重複定義。

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

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

系統緩存

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

寫出來是以爲本身能力有限，目前只總結到這個層次，歡迎各位拍磚。