[CAMCOCO][C#]個人系統架構.服務器端.（一）

儘可能少的前言

雖然寫了N年代碼了，但總以爲什麼東西都是囫圇吞棗，沒法盡得其精髓。最近整理了一套心目中的架構，若有錯誤之處，煩勞不吝指正，老胡在此不勝感激！！

 

第一篇 我心目中的架構

作了無數個系統，寫了無數個項目，有幾個問題始終困擾着我。

      老是重複作着一樣的功能，好比組織架構，好比權限模型；

      代碼質量老是沒法獲得根本性的保障；

      大量的功能性代碼重複，沒有被很好地抽象出來（其實就是設計模式沒有被很好地利用起來）；

      過一段時間後修改代碼很困難，由於代碼風格老是隨着時間在不斷變化，而且大部分時候代碼都是來自好幾我的的。

我想有一個架構，它能夠有如下一些特性：

　　一、利用EntityFramework實現ORM特性，在設計及編寫項目時，思路能最大程度地保持在業務自己，而不用跳出到數據庫設計上去；

　　二、借鑑DDD的設計思想，將業務邏輯封裝到聚合裏（實際上我是很想徹底採用DDD的，可是啃了半天書，由於沒有實際項目的實踐，在領域事件上仍以爲很模糊，而且對於聚合的實際應用方式也不是很清晰）；

　　三、將通用性的一些操做，好比增刪改查，抽象出來，放到業務邏輯的核心層去實現，每一個業務邏輯不用再本身實現。這樣上層重複代碼量將會少不少；

　　四、規範一些基本操做的代碼寫法，在最大程度上確保上層代碼質量的可控性；

　　五、經過SOA模式，實現包括一站式登錄、權限判斷、通用（經常使用）模塊的獨立運行；

　　六、業務邏輯層不侷限於對某一特定模式的UI層的支持，它應該可以普遍地支持WEB、MVC WEB、WINFORM、MOBILE（ios or android）端的調用；

　　總之，經過這個架構，我想可以在編寫具體業務功能的時候使用儘可能少、儘可能標準的代碼來實現。

 

　　基於此，我對整個架構進行了以下一個層次劃分：

01 UI 層代碼：這裏是各類客戶端的代碼，我在其下作了個01.01 MVC WEB Application的目錄，若是有其餘的客戶端，能夠在這下面實現，好比增長一個 01.02 WIN FORM Application。

02 SOA：爲界面層提供數據的服務層，這一層其實是一個數據中轉層。我將業務邏輯中的各個聚合都經過SOA暴露給客戶端，那麼不一樣的客戶端均可以經過統一的方式來對系統進行訪問了，實際上這一層也起到了一個防腐層的做用。固然，若是是本機運行的WIN FORM模式，或者不但願採用SOA模式，也能夠在UI層直接調用業務邏輯層。

03 Business Logic：業務邏輯層，在這裏面對不一樣的業務邏輯按照DDD的設計思想，設計爲不一樣的聚合（Aggregate），這一層也是須要咱們本身編寫的。SOA層與這一層進行通信。

04 Model Logic：模型層，也就是實體層。我將業務中的實體對象單獨拆分出來，沒有和業務層放到一塊兒，由於在UI層裏都會用到各個實體的定義，而業務邏輯層我並不想直接交給UI層去使用。UI只須要知道本身當前使用的實體有哪些屬性可使用就好。實體我採用的是充血模型，包括自我驗證等特性，這個會在後面說到。

05 Business Core：業務邏輯核心包（代碼），嚴格說來，帶Core名字後綴的都不是單獨的一層，只是一個基類。業務邏輯層的代碼都是從這個東西派生出來的，這裏麪包含了一些基本的、通用性的業務操做。

06 Model Core：實體層核心包，同上，我在這裏給定義了集中標準的實體模型基類，全部實體都須要從這些標準基類中派生出來。同時在這裏實現了一些實體的克隆、驗證等通用方法。

07 DATA：數據持久層。一直很糾結這裏究竟要怎麼作，尤爲是對不一樣數據庫的支持上，最後由於本身一直使用SQLSERVER，因此這裏直接就經過EntityFramework來實現了，EF自己就支持不少種數據庫，但沒測試過，至少在個人需求內，SQLSERVER是徹底沒問題的。

08 General：通用描述定義，這裏不能稱爲一層了，我把一些經常使用的數據類型進行了標準化，實體類在使用這類屬性的時候直接從通用描述定義裏取得就行，這樣利於實現數據格式的標準化，好比實現了數據鎖定狀態描述信息、數據過時狀態描述信息等。

09 Common：工具類，就是各類Helper，這裏的工具能夠根據須要隨時增長。

10 Reference Lib：引用的第三方類庫統一放到這個目錄下，方便查找。

11 Solution Documents：項目文檔什麼的，都放這裏就好。

12 Test Projects：單元測試代碼

13 Publish：項目發佈目錄

 

額，下一篇從最底層寫起...