一、前言 都說”不想做架構師的開發不是好前端“，”一千個讀者心中有一千個哈姆雷特“。我相信每個開發者心中，都有一個屬於自己的框架，所以今天我就給大家探討一下我心中的簡單分層架構設計。 在說分層架構設計之前，先說下我對架構設計的理解，不足之處還希望大神指點。《.NET應用架構設計》這本書裡面寫到：架構 ...
一、前言
都說”不想做架構師的開發不是好前端“，”一千個讀者心中有一千個哈姆雷特“。我相信每個開發者心中，都有一個屬於自己的框架，所以今天我就給大家探討一下我心中的簡單分層架構設計。
在說分層架構設計之前，先說下我對架構設計的理解，不足之處還希望大神指點。《.NET應用架構設計》這本書裡面寫到：架構設計其實為“架構”和”設計”的兩個概念，架構是對業務需求的高層抽象，而設計是將高層抽象的需求與具體的技術實現聯繫起來，在此過程中，會根據實際情況考慮到系統的穩定性、安全性、擴展性相容性等各種因素。所以在項目業務需求提出之後，經過架構分析，得到系統的機構方案，然後根據架構方案做不同的設計方案，選擇適合的設計方案進行開發。架構設計和代碼重構一樣，他不是一蹴而就的，他也是在迭代中變得完善和穩定。
說到這裡，我想說一下框架和模式，平常中或多或少都會看到xx框架、xx模式，架構設計主要體現在設計上面，他們輸出可能是文檔或者偽代碼等，而框架就是對架構設計的累計實現。比如工作中的項目框架，都是在我們經過多次設計、重構過後，得到公共模塊（也就是我們說的輪子），在這個基礎上，開發就會很便利。模式這是根據開發經驗，提出某些問題比較好的解決方案。比如說單例模式、工廠模式等。
當然架構設計肯定沒有說得這麼簡單，他還有很多設計原則和理論，感興趣的朋友可以自己去瞭解一下。
下麵就是蝸牛根據自己的理解，結合到一個例子對多層架構設計和實現，如果有不合理的地方，希望大家都多指點。
二、分層架構設計實現
一說到分層（這裡我們說的是邏輯分層），相信很多人都會想到經典的三層架構。其實分層的目的是把功能按照不同的角色分隔開，便於後期系統擴展、維護，所以三層只是一個最少的層次劃分，具體的層次需要根據項目實際的業務情況以及系統的部署情況進行劃分。下麵我就以一個項目進行說明。
現在需要實現一個論壇的項目，併發量等非業務因素現在都不做考慮，由於經費原因，只能提供一臺伺服器作為部署環境，可以支持PC端和手機端訪問。
我相信很多園友在做項目的時候，都遇到過這個情況，客戶只知道他想要這個東西，但是其他的，他一概沒考慮。由於這個是例子，就直接按照上面的需求做了，細節方面就後面再修改。
2.1、分層約束
2.2、分層描述
界面層：用戶界面或表現層，即MCV中的view層；
界面控制層和API介面層：界面控制層即MCV中的Control層（使用.net的mvc），API介面層主要以Webapi提供介面，主要用於實現輕業務、參數校驗、異常封裝以及許可權驗證；
業務邏輯層（Service層）：實現業務處理邏輯；
業務Manager層：可復用邏輯層，完成：1. 對第三方平臺封裝的層，預處理返回結果及轉化異常信息；2. 對Service層通用能力的下沉，如cache,mq等通用處理；
數據持久層（Dao層）：資料庫訪問層。
Common層：裡面主要包含業務方法庫和公共方法庫，業務方法庫：主要是協助業務邏輯層處理邏輯，即含業務的公共方法，只被業務邏輯層調用；公共方法庫：包含公共方法，可以被所有層調用。公共方法庫還有一個原則，就是他不依賴Model，他對於任何層次都可以單獨調用，以後作為框架的一個公共庫模塊。這也就是為什麼還會存在一個業務方法庫。
分層說明：因為界面層使用的MVC，所以對應的就有界面控制層，如果前後端分離，就只需要API介面層即可。
2.3、分層模型描述
Entity：主要是對資料庫表結構一一對應；
DTO：數據傳輸類型總稱，這裡將他作為一個象徵名詞，具體分為：Request（請求對象），Response（響應對象）和DTO（數據傳輸對象）。
模型運用場景：
界面層發送Request參數請求，界面控制層將請求分發到對應的Service層，Service層根據業務拆分成不同的DTO參數請求或者不做拆分，再發送到Dao層，Dao層訪問資料庫。如果是資料庫表查詢，返回Entity對象，如果是多表業務查詢，返回DTO對象，Service層經過業務處理返回Response對象到界面控制層，界面層直接返回Response對象。由於項目較小，返回過程中的Entity對象和DTO對象也可以直接返回。
2.4、實現技術
前端技術：html5,css3,javascript,jquery,layui以及它的fly論壇界面;
後端技術：採用.net MVC、WabAPI以及.net Framework為目標框架；類庫採用standard作為目標框架；ORM使用Dapper；依賴註入採用Unity；日誌框架使用Log4Net;
技術選型說明：界面層和界面控制層選用的是.net Framework為目標框架的.net MVC，而.net Core是以後的大勢，所以剩下的類庫都選用standard作為目標框架，後面如果使用.Net Core進行跨平臺，直接替換界面層和界面控制層即可。在研發過程中還會添加其他的技術，所以架構設計也要不斷的迭代。
2.5、編碼規範
這裡的規範只對架構方面的規範，至於代碼書寫的規範（命名，註釋等）就不做描述了。
1、命名規範
業務邏輯層（Service層）所有文件必須以Service結尾；
業務Manager層所有文件必須以Manage結尾；
數據持久層（Dao層）所有文件必須以Repository結尾；
Entity對象所有文件必須以Entity結尾；
界面層發送的請求必須以Request結尾；
返回給界面層的數據必須以Response結尾；
其餘的傳輸的數據對象必須以DTO結尾。
2、依賴註入
業務邏輯層（Service層），業務Manager層，數據持久層（Dao層）必須有對應的介面層，採用依賴註入的方式實例化對象。
3、方法庫
業務方法庫和公共方法庫都必須是靜態方法，並且業務方法庫只能被業務邏輯層（Service層）調用。
4、參數規範
所有的方法，請求和返回對象都必須一一對應。（主要是防止一個對象多用，導致後期混亂不堪）
5、文檔歸類
同一功能或者同一類型方法或者對象，需要用文件夾同一依賴。
備註：開發過程中還有其他的約定規範，後面不斷的迭代。
2.5、分層架構實現
先創建一個命名為“PFTSnailSystem”的空白解決方案，然後根據分層約束，我們將他們歸納為：CommonLayer、ModelLayer、BusinessLayer、DataLayer和PresentationLayer。為了給他們指定順序，所以在他們前邊加上編號。
如圖：
現在我們就將各層分別創建到指定的文件中。如圖：
，
註意：創建類庫一定選擇standard框架。
其中，PFT.Snail.Core為業務方法庫，PFT.Snail.Utility為公共方法庫。其他的項目跟前面分層描述一一對應，並且都有單獨的對應的介面類庫。
三、總結
到目前為止，我們整理好了架構，架構方案的樣子也在項目中有個輪廓了，雖然也存在著設計，但設計還沒做完。其實對於設計是否完成，也是仁者見仁智者見智，設計可以詳細到具體的UML類圖。前面，我們雖然對每層做了規範限制，也說明瞭項目的使用的相關技術，但是都說得很抽象。因為設計的結果，就是項目的“規格說明”，而我們現在的都沒有設計到項目需求，這個架構也可以適用到其他項目。所以後面我們將針對不同的功能模塊，先做設計方案，然後編寫實現設計方案，同時將逐步實現架構裡面的基礎功能。
