分層架構設計

1、前言

都說」不想作架構師的開發不是好前端「，」一千個讀者心中有一千個哈姆雷特「。我相信每一個開發者心中，都有一個屬於本身的框架，因此今天我就給你們探討一下我心中的簡單分層架構設計。

在說分層架構設計以前，先說下我對架構設計的理解，不足之處還但願大神指點。《.NET應用架構設計》這本書裏面寫到：架構設計其實爲「架構」和」設計」的兩個概念，架構是對業務需求的高層抽象，而設計是將高層抽象的需求與具體的技術實現聯繫起來，在此過程當中，會根據實際狀況考慮到系統的穩定性、安全性、擴展性兼容性等各類因素。因此在項目業務需求提出以後，通過架構分析，獲得系統的機構方案，而後根據架構方案作不一樣的設計方案，選擇適合的設計方案進行開發。架構設計和代碼重構同樣，他不是一蹴而就的，他也是在迭代中變得完善和穩定。

說到這裏，我想說一下框架和模式，日常中或多或少都會看到xx框架、xx模式，架構設計主要體如今設計上面，他們輸出多是文檔或者僞代碼等，而框架就是對架構設計的累計實現。好比工做中的項目框架，都是在咱們通過屢次設計、重構事後，獲得公共模塊（也就是咱們說的輪子），在這個基礎上，開發就會很便利。模式這是根據開發經驗，提出某些問題比較好的解決方案。好比說單例模式、工廠模式等。

固然架構設計確定沒有說得這麼簡單，他還有不少設計原則和理論，感興趣的朋友能夠本身去了解一下。

下面就是蝸牛根據本身的理解，結合到一個例子對多層架構設計和實現，若是有不合理的地方，但願你們都多指點。

2、分層架構設計實現

一說到分層（這裏咱們說的是邏輯分層），相信不少人都會想到經典的三層架構。其實分層的目的是把功能按照不一樣的角色分隔開，便於後期系統擴展、維護，因此三層只是一個最少的層次劃分，具體的層次須要根據項目實際的業務狀況以及系統的部署狀況進行劃分。下面我就以一個項目進行說明。

如今須要實現一個論壇的項目，併發量等非業務因素如今都不作考慮，因爲經費緣由，只能提供一臺服務器做爲部署環境，能夠支持PC端和手機端訪問。

我相信不少園友在作項目的時候，都遇到過這個狀況，客戶只知道他想要這個東西，可是其餘的，他一律沒考慮。因爲這個是例子，就直接按照上面的需求作了，細節方面就後面再修改。

2.一、分層約束

2.二、分層描述

界面層：用戶界面或表現層，即MCV中的view層；

界面控制層和API接口層：界面控制層即MCV中的Control層（使用.net的mvc），API接口層主要以Webapi提供接口，主要用於實現輕業務、參數校驗、異常封裝以及權限驗證；

業務邏輯層（Service層）：實現業務處理邏輯；

業務Manager層：可複用邏輯層，完成：1. 對第三方平臺封裝的層，預處理返回結果及轉化異常信息；2. 對Service層通用能力的下沉，如cache,mq等通用處理；

數據持久層（Dao層）：數據庫訪問層。

Common層：裏面主要包含業務方法庫和公共方法庫，業務方法庫：主要是協助業務邏輯層處理邏輯，即含業務的公共方法，只被業務邏輯層調用；公共方法庫：包含公共方法，能夠被全部層調用。公共方法庫還有一個原則，就是他不依賴Model，他對於任何層次均可以單獨調用，之後做爲框架的一個公共庫模塊。這也就是爲何還會存在一個業務方法庫。

分層說明：由於界面層使用的MVC，因此對應的就有界面控制層，若是先後端分離，就只須要API接口層便可。

2.三、分層模型描述

Entity：主要是對數據庫表結構一一對應；

DTO：數據傳輸類型總稱，這裏將他做爲一個象徵名詞，具體分爲：Request（請求對象），Response（響應對象）和DTO（數據傳輸對象）。

模型運用場景：

界面層發送Request參數請求，界面控制層將請求分發到對應的Service層，Service層根據業務拆分紅不一樣的DTO參數請求或者不作拆分，再發送到Dao層，Dao層訪問數據庫。若是是數據庫表查詢，返回Entity對象，若是是多表業務查詢，返回DTO對象，Service層通過業務處理返回Response對象到界面控制層，界面層直接返回Response對象。因爲項目較小，返回過程當中的Entity對象和DTO對象也能夠直接返回。

2.四、實現技術

前端技術：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.五、編碼規範

這裏的規範只對架構方面的規範，至於代碼書寫的規範（命名，註釋等）就不作描述了。

一、命名規範

業務邏輯層（Service層）全部文件必須以Service結尾；

業務Manager層全部文件必須以Manage結尾；

數據持久層（Dao層）全部文件必須以Repository結尾；

Entity對象全部文件必須以Entity結尾；

界面層發送的請求必須以Request結尾；

返回給界面層的數據必須以Response結尾；

其他的傳輸的數據對象必須以DTO結尾。

二、依賴注入

業務邏輯層（Service層），業務Manager層，數據持久層（Dao層）必須有對應的接口層，採用依賴注入的方式實例化對象。

三、方法庫

業務方法庫和公共方法庫都必須是靜態方法，而且業務方法庫只能被業務邏輯層（Service層）調用。

四、參數規範

全部的方法，請求和返回對象都必須一一對應。（主要是防止一個對象多用，致使後期混亂不堪）

五、文檔歸類

同一功能或者同一類型方法或者對象，須要用文件夾同一依賴。

備註：開發過程當中還有其餘的約定規範，後面不斷的迭代。

2.五、分層架構實現

先建立一個命名爲「PFTSnailSystem」的空白解決方案，而後根據分層約束，咱們將他們概括爲：CommonLayer、ModelLayer、BusinessLayer、DataLayer和PresentationLayer。爲了給他們指定順序，因此在他們前邊加上編號。

如圖：

如今咱們就將各層分別建立到指定的文件中。如圖：，

注意：建立類庫必定選擇standard框架。

其中，PFT.Snail.Core爲業務方法庫，PFT.Snail.Utility爲公共方法庫。其餘的項目跟前面分層描述一一對應，而且都有單獨的對應的接口類庫。

3、總結

到目前爲止，咱們整理好了架構，架構方案的樣子也在項目中有個輪廓了，雖然也存在着設計，但設計還沒作完。其實對於設計是否完成，也是仁者見仁智者見智，設計能夠詳細到具體的UML類圖。前面，咱們雖然對每層作了規範限制，也說明了項目的使用的相關技術，可是都說得很抽象。由於設計的結果，就是項目的「規格說明」，而咱們如今的都沒有設計到項目需求，這個架構也能夠適用到其餘項目。因此後面咱們將針對不一樣的功能模塊，先作設計方案，而後編寫實現設計方案，同時將逐步實現架構裏面的基礎功能。