盗墓笔记有声小说,辰东完美世界有声小说,盗墓笔记同人小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

創(chuàng)新互聯(lián)GoFrame教程：GoFrame工程開發(fā)設(shè)計-代碼分層設(shè)計

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

10多年的東港網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。成都全網(wǎng)營銷的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整東港建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)從事“東港網(wǎng)站設(shè)計”,“東港網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

一、基本介紹

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

二、MVC設(shè)計模式

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

簡要介紹

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

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

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

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

痛點描述

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

視圖展示與數(shù)據(jù)操作方式的進一步剝離，特別是移動端的發(fā)展，前端?MVVM?框架的發(fā)展，我們大多數(shù)場景下已不再需要服務端渲染?View?。
?MVC?的代碼分層設(shè)計模式其實粒度較粗：

?Model?層級的代碼既維護著數(shù)據(jù)，也封裝著業(yè)務邏輯，隨著業(yè)務邏輯變得越來越復雜，這一層功能邏輯會變得越來越臃腫不易維護。
對于團隊管理來講，?Controller?和?Model?的職責邊界比較模糊，很難保證參差不齊的團隊成員能夠清晰地認識到?Controller?層并不應當封裝業(yè)務邏輯。對于開發(fā)人員寫好代碼的要求會比較高。

三、3-Tier Architecture

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

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

表示層 - UI

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

業(yè)務邏輯層 - BLL

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

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

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

模型定義層 - Model

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

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

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

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

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

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

當前文章：創(chuàng)新互聯(lián)GoFrame教程：GoFrame工程開發(fā)設(shè)計-代碼分層設(shè)計
本文地址：http://fisionsoft.com.cn/article/dpgpghs.html