DASP

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

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

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

本文著錄格式：吳曉一. DASP——一種基于前后端分離架構的產品設計模式[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（模型-視圖-控制器）架構，以其耦合性低、復用性高等特點，多年以來，作為一種經典的軟件架構被業界廣泛使 ?用[1-5]。同時，MVC也有著代碼復雜、對模型訪問效率低下等缺點，因此很多研究嘗試著在MVC架構的基礎上加以改良[6-7]。

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

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

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

1 ?前后端分離架構

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

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

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

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

因此，理想的前后端開發理應與主從式架構保持高度的一致和統一。即，前端只負責客戶端的用戶界面，后端只負責在服務端提供服務。客戶端向服務端提交調用某種服務的請求，服務端就做出響應并將結果返回給客戶端。

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

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

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

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

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

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

2 ?CAD最簡模型

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

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

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

3 ?DASP設計模式

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

3.1 ?數據庫設計（Database）

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

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

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

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

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

3.2 ?接口設計（API）

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

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

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

3.3 ?結構設計（Structure）

結構設計就是以產品的視覺結構為導向，將產品的構造逐級逐層細分，并確定UI要素與API接口的對應關系，以實現視覺要素與產品功能的協調統一。

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

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

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

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

3.4 ?原型設計（Prototype）

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

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

4 ?設計實例分析

4.1 ?產品概要

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

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

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

根據上述描述將該產品的用例圖描繪出來的話，如圖2所示。

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

4.2 ?BBS案例的數據庫設計

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

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

4.3 ?BBS案例的接口設計

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

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

4.4 ?BBS案例的結構設計

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

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

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

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

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

4.5 ?BBS案例的原型設計

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

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

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

5 ?結語

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

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

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

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

參考文獻

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

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

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

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

[5] 湯明偉， 鄭柳娟. 基于 MVC 的響應式餐飲業工服供應鏈分銷平臺的設計與實現[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框架的開發[J]. 電腦編程技巧與維護， 2016（23）： 5-8.

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

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