GoFrame 工程開發(fā)設(shè)計(jì)-代碼分層設(shè)計(jì)

代碼分層的意義在于將程序邏輯進(jìn)一步解耦，將層級(jí)之間的數(shù)據(jù)流和依賴關(guān)系設(shè)計(jì)為單向鏈路，使得系統(tǒng)架構(gòu)更加靈活易擴(kuò)展。

一、基本介紹

?GoFrame?作為一款工程化完備的基礎(chǔ)開發(fā)框架，有其獨(dú)特的框架設(shè)計(jì)理念，這一章節(jié)我們來介紹一下她的代碼分層設(shè)計(jì)。對(duì)于服務(wù)端業(yè)務(wù)代碼的分層設(shè)計(jì)模式中，我們比較常見的是?MVC?設(shè)計(jì)模式和三層架構(gòu)設(shè)計(jì)模式(?3-Tier Architecture?)

二、MVC設(shè)計(jì)模式

我們先來回顧一下經(jīng)典的?MVC?設(shè)計(jì)模式。

簡(jiǎn)要介紹

?M?代表模型(?Model?)，表示業(yè)務(wù)規(guī)則封裝。在?MVC?的三個(gè)部件中，模型擁有最多的處理任務(wù)。被模型返回的數(shù)據(jù)是中立的，模型與數(shù)據(jù)格式無關(guān)，這樣一個(gè)模型能為多個(gè)視圖提供數(shù)據(jù)，由于應(yīng)用于模型的代碼只需寫一次就可以被多個(gè)視圖重用，所以減少了代碼的重復(fù)性。

?V?代表視圖(?View?)，用戶看到并與之交互的界面。比如由?HTML?元素組成的網(wǎng)頁(yè)界面，或者軟件的客戶端界面。?MVC?的好處之一在于它能為應(yīng)用程序處理很多不同的視圖。在視圖中其實(shí)沒有真正的處理發(fā)生，它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。

?C?代表控制器(?Controller?)，接受用戶的輸入并調(diào)用模型和視圖去完成用戶的需求，控制器本身不輸出任何東西和做任何處理。它只是接收請(qǐng)求并決定調(diào)用哪個(gè)模型構(gòu)件去處理請(qǐng)求，然后再確定用哪個(gè)視圖來顯示返回的數(shù)據(jù)。

這種設(shè)計(jì)模式比較簡(jiǎn)單，比較合適于需要服務(wù)端渲染頁(yè)面的業(yè)務(wù)場(chǎng)景，對(duì)于?SEO?來說也比較友好。但隨著?MVVM?開發(fā)模式的興起，以及前端技術(shù)的快速發(fā)展，特別是一些前端開發(fā)框架如?Vue?、?React?、?Angular?之類的項(xiàng)目出現(xiàn)，服務(wù)端的?MVC?設(shè)計(jì)模式使用場(chǎng)景變得越來越少。

痛點(diǎn)描述

針對(duì)于業(yè)務(wù)邏輯并不是特別復(fù)雜的業(yè)務(wù)場(chǎng)景項(xiàng)目，?MVC?還能游刃有余，但隨著業(yè)務(wù)邏輯變得龐大復(fù)雜，?MVC?設(shè)計(jì)模式的項(xiàng)目維護(hù)成本上升的問題變得越來越明顯。特別是隨著互聯(lián)網(wǎng)項(xiàng)目微服務(wù)架構(gòu)的發(fā)展，?MVC?設(shè)計(jì)模式在大部分的互聯(lián)網(wǎng)項(xiàng)目開發(fā)中變得越來越雞肋。究其原因，主要的幾點(diǎn)：

• 視圖展示與數(shù)據(jù)操作方式的進(jìn)一步剝離，特別是移動(dòng)端的發(fā)展，前端?MVVM?框架的發(fā)展，我們大多數(shù)場(chǎng)景下已不再需要服務(wù)端渲染?View?。
• ?MVC?的代碼分層設(shè)計(jì)模式其實(shí)粒度較粗：
• ?Model?層級(jí)的代碼既維護(hù)著數(shù)據(jù)，也封裝著業(yè)務(wù)邏輯，隨著業(yè)務(wù)邏輯變得越來越復(fù)雜，這一層功能邏輯會(huì)變得越來越臃腫不易維護(hù)。
• 對(duì)于團(tuán)隊(duì)管理來講，?Controller?和?Model?的職責(zé)邊界比較模糊，很難保證參差不齊的團(tuán)隊(duì)成員能夠清晰地認(rèn)識(shí)到?Controller?層并不應(yīng)當(dāng)封裝業(yè)務(wù)邏輯。對(duì)于開發(fā)人員寫好代碼的要求會(huì)比較高。

三、3-Tier Architecture

?GoFrame?框架推薦的代碼分層設(shè)計(jì)模式為三層架構(gòu)設(shè)計(jì)（?3-Tier Architecture?）。三層架構(gòu)設(shè)計(jì)能夠很好地體現(xiàn)出軟件設(shè)計(jì)"高內(nèi)聚，低耦合"的設(shè)計(jì)思想。

傳統(tǒng)的三層架構(gòu)設(shè)計(jì)如上圖，將項(xiàng)目代碼劃分了三層，每一層有其獨(dú)自的職責(zé)邊界。但在大多數(shù)的場(chǎng)景中，我們常看到的是以下的分層結(jié)構(gòu)，將數(shù)據(jù)結(jié)構(gòu)模型再進(jìn)一步地抽離了出來統(tǒng)一維護(hù)。

表示層 - UI

?User Interface?位于三層構(gòu)架的最上層，與用戶直接接觸，主要是?B/S?中的 ?WEB?頁(yè)面，也可以是?API?接口。表示層的主要功能是實(shí)現(xiàn)系統(tǒng)數(shù)據(jù)的傳入與輸出，在此過程中不需要借助邏輯判斷操作就可以將數(shù)據(jù)傳送到BLL系統(tǒng)中進(jìn)行數(shù)據(jù)處理，處理后會(huì)將處理結(jié)果反饋到表示層中。換句話說，表示層就是實(shí)現(xiàn)用戶界面/?API?接口功能，將用戶的需求傳達(dá)和反饋，并用?BLL?或者是?Model?進(jìn)行調(diào)試，保證用戶體驗(yàn)。

業(yè)務(wù)邏輯層 - BLL

?Business Logic Layer?的功能是對(duì)具體問題進(jìn)行邏輯判斷與執(zhí)行操作，接收到表現(xiàn)層?UI?的用戶指令后，會(huì)連接數(shù)據(jù)訪問層?DAL?，業(yè)務(wù)邏輯層在三層構(gòu)架中位于表示層與數(shù)據(jù)層中間位置，同時(shí)也是表示層與數(shù)據(jù)層的橋梁，實(shí)現(xiàn)三層之間的數(shù)據(jù)連接和指令傳達(dá)，可以對(duì)接收數(shù)據(jù)進(jìn)行邏輯處理，實(shí)現(xiàn)數(shù)據(jù)的增刪改查等功能，并將處理結(jié)果反饋到表示層?UI?中，實(shí)現(xiàn)軟件功能。

數(shù)據(jù)訪問層 - DAL

?Data Access Layer?是數(shù)據(jù)庫(kù)的主要操控系統(tǒng)，實(shí)現(xiàn)數(shù)據(jù)的增刪改查等操作，并將操作結(jié)果反饋到業(yè)務(wù)邏輯層?BLL?。在實(shí)際運(yùn)行的過程中，數(shù)據(jù)訪問層沒有邏輯判斷能力，為了實(shí)現(xiàn)代碼編寫的嚴(yán)謹(jǐn)性，提高代碼閱讀程度，一般軟件開發(fā)人員會(huì)在該層中實(shí)現(xiàn)通用數(shù)據(jù)能力進(jìn)行封裝（例如通過?ORM?組件）來保證數(shù)據(jù)訪問層?DAL?數(shù)據(jù)處理功能。

模型定義層 - Model

模型定義也常用?Entity?實(shí)體對(duì)象來表示，主要用于數(shù)據(jù)庫(kù)表的映射對(duì)象，在信息系統(tǒng)軟件實(shí)際開發(fā)的過程中，要建立對(duì)象實(shí)例，將關(guān)系數(shù)據(jù)庫(kù)表采用對(duì)象實(shí)體化的方式表現(xiàn)出來，輔助軟件開發(fā)中對(duì)各個(gè)系統(tǒng)功能的控制與操作執(zhí)行。建立實(shí)體類庫(kù)，進(jìn)而實(shí)現(xiàn)各個(gè)結(jié)構(gòu)層的參數(shù)傳輸，提高代碼的閱讀性。從本質(zhì)上看，實(shí)體類庫(kù)主要服務(wù)于表示層、業(yè)務(wù)邏輯層以及數(shù)據(jù)訪問層，在三層之間進(jìn)行數(shù)據(jù)參數(shù)傳輸，強(qiáng)化數(shù)據(jù)表示的簡(jiǎn)約性。

需要注意區(qū)分的是，這里的?Model?和?MVC?設(shè)計(jì)模式中的?Model?雖然都是一個(gè)名字但是差別巨大，職責(zé)完全不同。

三層架構(gòu)設(shè)計(jì)與MVC

由于?MVC?也是三層結(jié)構(gòu)，因此有的同學(xué)也會(huì)將?MVC?籠統(tǒng)地歸納于三層架構(gòu)設(shè)計(jì)中，從字面意義上來講似乎也沒什么問題。不過兩者還是存在一定的區(qū)別。

可以看到，在三層架構(gòu)設(shè)計(jì)中，?UI?表示層即相當(dāng)于?MVC?的?View?和?Controller?層，原本在?MVC?中這兩層的邏輯應(yīng)當(dāng)是比較"輕量"的，因此被合并為一層進(jìn)行統(tǒng)一管理也可以理解。比較重要的一點(diǎn)是，原本?MVC?中的?Model?被拆分為了?BLL?和?DAL?，即將業(yè)務(wù)邏輯與數(shù)據(jù)訪問進(jìn)行分離，將原本臃腫的?Model?進(jìn)行了進(jìn)一步的解耦，有利于項(xiàng)目的更好維護(hù)。

軟件架構(gòu)的演變過程，特別是互聯(lián)網(wǎng)軟件架構(gòu)的演變過程，本質(zhì)也就是將業(yè)務(wù)邏輯不斷解耦的過程。