DASP

摘 ?要： MVC架構作為一種經(jīng)典的軟件架構，多年以來被業(yè)界廣泛使用。但由于MVC代碼復雜、效率低下等缺點，很多研究嘗試對其進行改良。近年來，伴隨著RESTful API的提出，以及前端框架的流行，前后端分離架構逐漸開始取代傳統(tǒng)的MVC架構成為業(yè)界主流。本文基于前后端分離架構提出了一個由客戶端、接口和數(shù)據(jù)庫構成的最簡模型，在該模型的基礎上又提出了一個簡潔、高效的產(chǎn)品設計模式（DASP）。并以一個電子留言板的實際案例詳細闡述了該模式的具體設計流程，表明了該模式的有效性和高效性。

關鍵詞： DASP;前后端分離;設計模式;RESTful API

中圖分類號： TP3 ? ?文獻標識碼： A ? ?DOI：10.3969/j.issn.1003-6970.2020.08.047

本文著錄格式：吳曉一. DASP——一種基于前后端分離架構的產(chǎn)品設計模式[J]. 軟件，2020，41（08）：175-179

【Abstract】： As a classical software architecture， MVC architecture has been widely used in the industry for many years. However， due to the complexity and low efficiency of MVC， many studies have tried to improve it. In recent years， with the introduction of RESTful APIs and the popularity of front-end frameworks， the front-end and back-end separation architectures have gradually begun to replace the traditional MVC architecture and become the mainstream of the industry. This paper proposes a simple model consisting of client， interface and database based on the front-end and back-end separation architecture. Based on this model， a simple and efficient product design pattern （DASP） is proposed. An actual case of BBS is used to elaborate on the specific design process， indicating the effectiveness and efficiency of this pattern.

【Key words】： DASP; Front-end separation; Design pattern; RESTful API

0 ?引言

MVC架構，又名Model-View-Controller（模型-視圖-控制器）架構，以其耦合性低、復用性高等特點，多年以來，作為一種經(jīng)典的軟件架構被業(yè)界廣泛使 ?用[1-5]。同時，MVC也有著代碼復雜、對模型訪問效率低下等缺點，因此很多研究嘗試著在MVC架構的基礎上加以改良[6-7]。

但由于MVC架構的自身局限，前后端的業(yè)務很難被徹底分開，其結果就造成了本該明確分工的各種業(yè)務揉雜在一起，給開發(fā)帶來了諸多低效與不便。

對此，F(xiàn)ielding提出了REST（REpresentational State Transfer）的概念，意為表述性狀態(tài)轉(zhuǎn)移，為在實際開發(fā)過程中前后端分工不明、職責不清的問題給出了一個很好的解決方案[8]。在后端只需準備好各種類似設計的接口，每當客戶端的請求方法和請求URI發(fā)過來，就調(diào)用符合該請求的接口，返回相應的狀態(tài)碼和以JSON格式承載的響應體。這類符合REST設計風格的程序接口就可以稱為RESTful API。

而前端方面，近年來，伴隨著Angular、React和Vue三大前端框架的流行，前后端分離架構也日趨成熟，業(yè)務與視圖在開發(fā)過程中徹底實現(xiàn)了分離：后端只實現(xiàn)API接口，前端只專注于設計用戶界面。這不僅實現(xiàn)了開發(fā)者的職責分離，也實現(xiàn)了前后端技術上的分離，為高效開發(fā)奠定了堅實的基礎[9-11]。

1 ?前后端分離架構

從軟件工程的角度，開發(fā)工作可拆分為兩種基本分工：前端（front-end）和后端（back-end）。

所謂前端，簡單來說，就是用戶看到的用戶交互界面和各種數(shù)據(jù)的展示。而后端，則是具體業(yè)務邏輯的實現(xiàn)和數(shù)據(jù)的持久存儲。

以用戶注冊為例，用戶能夠直接接觸到的只有一些可以輸入用戶名和密碼等個人信息的輸入框以及一個提交注冊請求的按鈕，這些看得見摸得著的就是前端;而在用戶提交請求后，需要判斷用戶提交的數(shù)據(jù)是否符合要求，如果符合要求則將提交數(shù)據(jù)寫入數(shù)據(jù)庫，這些用戶無法直接接觸到的處理過程便是后端。

如果單從客戶端-服務器這種主從式架構（client- server model）考慮，客戶端可以被寬泛地理解為與前端開發(fā)對應，而服務端也相應地的與后端開發(fā)對應。

因此，理想的前后端開發(fā)理應與主從式架構保持高度的一致和統(tǒng)一。即，前端只負責客戶端的用戶界面，后端只負責在服務端提供服務?？蛻舳讼蚍斩颂峤徽{(diào)用某種服務的請求，服務端就做出響應并將結果返回給客戶端。

然而，在傳統(tǒng)的實際開發(fā)過程中，比如經(jīng)典的MVC（模型-視圖-控制器）模式，前后端的業(yè)務很難被徹底分開，導致前后端業(yè)務揉雜在一起，大大影響開發(fā)效率。

2000年，Roy Fielding在其博士論文中提出了REST（REpresentational State Transfer，表述性狀態(tài)轉(zhuǎn)移）的概念[8]，即網(wǎng)絡資源在某種表現(xiàn)形式下實現(xiàn)狀態(tài)變化。網(wǎng)絡資源，指的是存儲在服務器中的信息資源，一般使用地址加復數(shù)名詞的形式來表示，比如http：//api.test.com/users就表示了該地址（http：//api.test. com/）下的所有用戶資源。

至于某種表現(xiàn)形式，無論是客戶端到服務端，還是服務端到客戶端，都使用JSON格式來呈現(xiàn)。

而該資源的狀態(tài)變化則由作為動詞的http請求方法（GET、POST、PATCH、DELETE）決定。具體例子如表1所示。

于是，在后端只需準備好各種類似設計的接口，每當客戶端的請求方法和請求URI發(fā)過來，就調(diào)用符合該請求的接口，返回相應的狀態(tài)碼和以JSON格式承載的響應體就可以了。這類符合REST設計風格的程序接口就可以稱為RESTful API。

基于RESTful API，前、后端在開發(fā)過程中就可以實現(xiàn)徹底分離：后端只實現(xiàn)API接口，前端只專注于設計用戶界面。如此一來，不僅實現(xiàn)了開發(fā)者的職責分離，也實現(xiàn)了前后端技術上的分離。

2 ?CAD最簡模型

后端的開發(fā)工作除了API接口外，還需涉及數(shù)據(jù)的永久性存儲。在數(shù)據(jù)庫設計過程中，往往需要先將與產(chǎn)品相關的，一切現(xiàn)實或觀念上的物體通過抽象建模，化作數(shù)據(jù)庫中的實體（entity），亦即RESTful API中以名詞復數(shù)表示的網(wǎng)絡資源，例如，將用戶相關信息抽象化作users。而針對數(shù)據(jù)庫實體的基本操作，又無外乎CRUD（Create、Read、Update、Delete），即增、查、改、刪四個動詞，這又恰恰與四種http請求方法POST、GET、PATCH、DELETE一一對應。這就使得數(shù)據(jù)庫與API接口完美有機地結合在一起。比如，客戶端使用POST方法調(diào)用/api/users接口，就在數(shù)據(jù)庫中新增一個用戶，使用GET方法調(diào)用/api/users接口，則返回用戶信息。

本文將這種僅使用POST、GET、PATCH、DELETE四種http請求方法的前后端分離架構模型稱為CAD（即Client-API-Database）最簡模型，該模型結構如圖1所示。

于是，后端方面的工作可進一步描述為：實現(xiàn)對數(shù)據(jù)庫增改查刪的RESTful API接口。服務器在接受用戶請求時，倘若找到匹配該請求的接口，則允許客戶端調(diào)用。對應不同的請求方法，針對數(shù)據(jù)庫資源也采取不同的操作方式。操作過后，將響應結果以JSON格式返回給客戶端。這就徹底實現(xiàn)了客戶端http請求、API接口與數(shù)據(jù)庫操作三者的高度統(tǒng)一。如表2所示。

3 ?DASP設計模式

因此，高效的設計過程理應與此基本模型保持高度一致。即，①對現(xiàn)實問題建模，完成數(shù)據(jù)庫（Database）的設計;②基于①，完成接口（API）的設計;③基于②，完成產(chǎn)品結構（Structure）設計;④基于③，完成產(chǎn)品原型（Prototype）設計，將產(chǎn)品結構視覺化為UI。本文將這種設計模式稱為DASP設計模式。

3.1 ?數(shù)據(jù)庫設計（Database）

所謂數(shù)據(jù)庫設計就是基于產(chǎn)品分析，從中提煉出數(shù)據(jù)實體、相關屬性以及相互關系。這可以通過ER圖（Entity Relationship Diagram），即實體-聯(lián)系圖來實現(xiàn)。

ER圖由三個要素構成，分別是實體、屬性和聯(lián)系。

實體就是在人的認知上能夠相互區(qū)分的事物，這個事物可以是現(xiàn)實中的具體事物，也可以是抽象上的概念。在ER圖中使用矩形框表示。

屬性是實體的特性，也是實體所具備的，可以用數(shù)據(jù)進行刻畫的方面。在ER圖中使用橢圓形表示，主屬性名下還需要加上下劃線。

聯(lián)系表示實體之間的關系，也就是以何種方式關聯(lián)在一起。在ER圖中以菱形表示，菱形兩邊需要通過連線將相關實體連接起來。除此之外，連線上還要標注出實體關聯(lián)的模式：一對一（1∶1）、一對多（1∶N）還是多對多（M∶N）。

3.2 ?接口設計（API）

在完成ER圖后，就可以進行接口設計了，目的是結合用例圖中的用例以及ER圖中的實體與屬性設計出清晰合理的RESTful API接口。API接口將用戶的一次次請求盡數(shù)化作對數(shù)據(jù)庫的增改查刪，是連接需求與信息之間的橋梁。

基于RESTful API標準，將產(chǎn)品的每個用例（即用戶實際可做出的行為）都封裝成一個API，規(guī)定請求方法和請求URI：請求方法為POST、GET、PATCH、DELETE其中之一，分別對應對數(shù)據(jù)的增查改刪。

在這個階段尚無須考慮實際業(yè)務邏輯的具體實現(xiàn)，只需要設計好輸入與輸出就可以了。對API來說，輸入就是用戶從客戶端向服務器發(fā)出的請求，輸出就是服務器向客戶端返回的響應。其中，無論請求體還是響應體都以JSON格式承載。

3.3 ?結構設計（Structure）

結構設計就是以產(chǎn)品的視覺結構為導向，將產(chǎn)品的構造逐級逐層細分，并確定UI要素與API接口的對應關系，以實現(xiàn)視覺要素與產(chǎn)品功能的協(xié)調(diào)統(tǒng)一。

設計結構圖，首先要從產(chǎn)品的基本模塊（或頻道）出發(fā)，確定好產(chǎn)品的模塊構成，作為結構的第一層。

每個模塊又可能由多個頁面構成。所以在第二層，就要具體設計出每個模塊所包含的頁面。

到了第三層，需要將頁面再細分為構成元素，這也是日后進行UI組件化開發(fā)的基礎。

第四層就是調(diào)用層，這是連接UI與API的層，也是真正實現(xiàn)產(chǎn)品功能，即用戶需求的層。在這一層中所調(diào)用的API一定要嚴格遵循3.2的接口設計，并確保無遺漏。

3.4 ?原型設計（Prototype）

所謂原型，就是以圖形化的方式表現(xiàn)的產(chǎn)品框架。它可以以一種極為直觀的方式展現(xiàn)出成品的樣態(tài)。既能夠在實際投入開發(fā)前得到客戶的意見反饋、降低返工風險，又是連接產(chǎn)品設計和實際開發(fā)的過渡階段，起到重要的承上啟下的作用。

在3.3中完成的產(chǎn)品結構圖是原型設計的重要參照依據(jù)。原型設計的過程也可以看作是將產(chǎn)品結構圖徹底視覺化的過程。

4 ?設計實例分析

4.1 ?產(chǎn)品概要

本文以一個BBS（電子留言板）為例，基于上述DASP設計模式的原則，詳細闡述其設計流程。

BBS的基本功能是解決用戶在線上圍繞某個話題的基本溝通需求。本例中將產(chǎn)品的使用者分為兩種，一種是未登陸的游客，一種是已經(jīng)登陸后的實際用戶。二者都有權瀏覽BBS的帖子，包含帖子列表以及具體的帖子信息。

除了瀏覽帖子這個共同行為外，游客可以注冊或登陸，以轉(zhuǎn)化為用戶身份。用戶則可以通過退出登陸而轉(zhuǎn)化為游客。在用戶處于登陸狀態(tài)時，還可以對用戶自身信息做出修改或是針對某個特定帖子進行操作。

根據(jù)上述描述將該產(chǎn)品的用例圖描繪出來的話，如圖2所示。

用例圖根據(jù)用戶想做什么而描述了利用產(chǎn)品能做什么，作為結果，也就初步規(guī)定了產(chǎn)品在功能上會有什么。既明確了數(shù)據(jù)庫設計中的實體及關系，也為API接口提供了直接的設計依據(jù)。

4.2 ?BBS案例的數(shù)據(jù)庫設計

在BBS例子里，用戶、帖子和回復就可以看作是實體，在數(shù)據(jù)庫中將對應一個個表。而用戶的ID，帖子的內(nèi)容，回復的發(fā)表時間就都是屬性，在數(shù)據(jù)庫中將對應表的列，也就是“字段”。一個帖子允許有多個用戶回復，這就說明帖子與回復的關系是1：N模式。

綜合以上規(guī)則將BBS項目數(shù)據(jù)化并用ER圖表現(xiàn)出來，效果如圖3所示。同時，為了方便實際開發(fā)過程中的數(shù)據(jù)建模，也可以用英文標出將來會實際使用的實體名和屬性名，其中，實體名首字母要大寫，屬性名保持小寫。

4.3 ?BBS案例的接口設計

在產(chǎn)品用例圖（圖2）中，每一個橢圓上的文字都是動詞或動賓短語構成，各自對應一個用戶行為實例，動詞方面，都可以看作是對數(shù)據(jù)庫的增查改刪操作，名詞則可以看作“表述性狀態(tài)轉(zhuǎn)移”中的網(wǎng)絡資源。將二者結合后，可直接轉(zhuǎn)化為符合RESTful API接口規(guī)范的設計。

這個列表可以為日后的接口開發(fā)工作提供實際參照標準。

4.4 ?BBS案例的結構設計

在3.3中所述的四個層次，可作為結構圖的橫軸。而產(chǎn)品本身的模塊，可作為結構圖的縱軸。

BBS系統(tǒng)，在結構圖的第一層，即模塊層來看，大致可劃分為三：首頁、帖子和個人中心，在導航欄中自由切換。

每個模塊在第二層中又可細化為多個頁面，比如帖子模塊，就需要一個瀏覽帖子列表的頁面，單擊其中的某個帖子后，再進到該帖子內(nèi)容的頁面。這兩個頁面都和帖子相關，所以歸在同一個模塊里。

在第三層中，每個頁面又由多個頁面元素構成，比如帖子列表頁面中，既要包含一個用來瀏覽的列表，也要包含一個發(fā)布帖子的表單。這個列表和表單可以作為組件任務分派給不同的人去實現(xiàn)，最后由項目的負責人組裝到一個頁面中。

第四層則基于4.3所設計的API接口列表，決定各頁面元素所實際調(diào)用的接口。最終完成的產(chǎn)品結構圖如圖4所示。

4.5 ?BBS案例的原型設計

原型設計方面可以通過手繪，也可以使用現(xiàn)成的原型設計工具。其中，使用范圍最廣的，也最受產(chǎn)品經(jīng)理所青睞的工具是Axure（官網(wǎng)：https：//www.axure. com/），這是一款收費軟件。要找免費替代品的話，有國產(chǎn)的墨刀（官網(wǎng)：https：//modao.cc/）和摹客（官網(wǎng)：https：//www.mockplus.cn/）：墨刀一般使用網(wǎng)頁版，屬于在線原型設計工具;而摹客（Mockplus）則是離線的桌面端軟件。兩者都是基礎功能免費，高級功能收費。

在4.4中所完成的產(chǎn)品結構圖（圖4），本就是以視覺結構為導向，將產(chǎn)品構造逐級細分得到的。因此，產(chǎn)品結構圖天然蘊含著原型化的基因。在原型設計過程中，也要嚴格遵循結構圖中所確定的組件結構乃至命名規(guī)范，為日后無縫過渡到UI開發(fā)打好基礎。

以摹客為例，在完成原型設計后，單擊左上樹狀圖中的【腦圖編輯模式】按鈕，可顯示腦圖如圖5。其構造與結構圖完全一致。

5 ?結語

本文以前后端分離架構為前提，以高效率設計為導向，提出了僅由客戶端、API接口和數(shù)據(jù)庫三部分構成、且僅使用POST、GET、PATCH、DELETE四種http請求方法的CAD最簡模型。

在這個最簡模型中，用戶的所有行為都簡化作四種http請求，分別對應針對數(shù)據(jù)的增查改刪，這在保證開發(fā)工作權責明確的同時，又實現(xiàn)了設計工作的高度統(tǒng)一。

基于CAD最簡模型，本文進而提出了DASP設計模式：即①基于產(chǎn)品用例圖首先完成數(shù)據(jù)庫方面的ER圖設計，明確數(shù)據(jù)存儲的實體、屬性及聯(lián)系;②基于產(chǎn)品用例圖和ER圖，完成API接口設計，架起前端與后端，或者說，客戶行為與數(shù)據(jù)操作之間的橋梁;③基于產(chǎn)品構成，逐步按照四個層次：模塊層、頁面層、元素層和調(diào)用層，不斷細化、具體化，以完成產(chǎn)品的結構圖，實現(xiàn)視覺要素與產(chǎn)品功能的統(tǒng)一;④基于產(chǎn)品結構圖，將其視覺化的要素徹底組織、布局并成形，以完成原型設計。

本文還以一個BBS（電子留言板）為例，詳細闡述了該DASP模式的具體設計流程。這個設計流程不僅因與CAD最小模型高度一致而實現(xiàn)了設計高效，也從客戶端、接口、數(shù)據(jù)庫這三個方面具體且詳細地規(guī)定了產(chǎn)品的規(guī)格，為之后的實際開發(fā)工作打下堅實的基礎。

參考文獻

[1] 任中方， 張華， 閆明松， 等. MVC模式研究的綜述[J]. 計算機應用研究， 2004（10）： 1-4+8.

[2] 韓凌波. 基于mvc架構的普法考試系統(tǒng)設計與實現(xiàn)[J]. 軟件， 2015， 36（3）： 132-134.

[3] 許戈， 鄭廣成. 基于NET MVC 的高職科技項目經(jīng)費報銷系統(tǒng)設計與實現(xiàn)[J]. 軟件， 2015， 36（10）： 36-39.

[4] 姚云飛， 杜洪波， 梁建輝. 基于 SpringMVC 框架畢業(yè)設計管理系統(tǒng)設計[J]. 軟件， 2018， 39（01）： 91-93.

[5] 湯明偉， 鄭柳娟. 基于 MVC 的響應式餐飲業(yè)工服供應鏈分銷平臺的設計與實現(xiàn)[J]. 軟件， 2018， 39（3）： 160-165.

[6] 黎永良， 崔杜武. MVC設計模式的改進與應用[J]. 計算機工程， 2005（09）： 96-97+212.

[7] 劉紅霞， 陸文迪. 改進的MVC設計模式的研究與應用[J]. 計算機工程與科學， 2015， 37（09）： 1688-1691.

[8] Fielding RT. Architectural styles and the design of network-based software architectures. 2000. University of California， Irvine. 2000： 162.

[9] 林嘉婷. 試談前后端分離及基于前端MVC框架的開發(fā)[J]. 電腦編程技巧與維護， 2016（23）： 5-8.

[10] 李宇， 劉彬. 前后端分離框架在軟件設計中的應用[J]. 無線互聯(lián)科技， 2018， 15（17）： 41-42.

[11] 張鵬飛， 王乾， 胡曉冬， 等. 基于Node. js和JS的前后端分離實現(xiàn)[J]. 軟件， 2019， 40（04）： 11-17.