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

關(guān)鍵詞： DASP;前后端分離;設(shè)計(jì)模式;RESTful API

中圖分類號(hào)： TP3 ? ?文獻(xiàn)標(biāo)識(shí)碼： A ? ?DOI：10.3969/j.issn.1003-6970.2020.08.047

本文著錄格式：吳曉一. DASP——一種基于前后端分離架構(gòu)的產(chǎn)品設(shè)計(jì)模式[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架構(gòu)，又名Model-View-Controller（模型-視圖-控制器）架構(gòu)，以其耦合性低、復(fù)用性高等特點(diǎn)，多年以來(lái)，作為一種經(jīng)典的軟件架構(gòu)被業(yè)界廣泛使 ?用[1-5]。同時(shí)，MVC也有著代碼復(fù)雜、對(duì)模型訪問(wèn)效率低下等缺點(diǎn)，因此很多研究嘗試著在MVC架構(gòu)的基礎(chǔ)上加以改良[6-7]。

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

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

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

1 ?前后端分離架構(gòu)

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

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

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

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

因此，理想的前后端開(kāi)發(fā)理應(yīng)與主從式架構(gòu)保持高度的一致和統(tǒng)一。即，前端只負(fù)責(zé)客戶端的用戶界面，后端只負(fù)責(zé)在服務(wù)端提供服務(wù)?？蛻舳讼蚍?wù)端提交調(diào)用某種服務(wù)的請(qǐng)求，服務(wù)端就做出響應(yīng)并將結(jié)果返回給客戶端。

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

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

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

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

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

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

2 ?CAD最簡(jiǎn)模型

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

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

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

3 ?DASP設(shè)計(jì)模式

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

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

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

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

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

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

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

3.2 ?接口設(shè)計(jì)（API）

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

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

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

3.3 ?結(jié)構(gòu)設(shè)計(jì)（Structure）

結(jié)構(gòu)設(shè)計(jì)就是以產(chǎn)品的視覺(jué)結(jié)構(gòu)為導(dǎo)向，將產(chǎn)品的構(gòu)造逐級(jí)逐層細(xì)分，并確定UI要素與API接口的對(duì)應(yīng)關(guān)系，以實(shí)現(xiàn)視覺(jué)要素與產(chǎn)品功能的協(xié)調(diào)統(tǒng)一。

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

每個(gè)模塊又可能由多個(gè)頁(yè)面構(gòu)成。所以在第二層，就要具體設(shè)計(jì)出每個(gè)模塊所包含的頁(yè)面。

到了第三層，需要將頁(yè)面再細(xì)分為構(gòu)成元素，這也是日后進(jìn)行UI組件化開(kāi)發(fā)的基礎(chǔ)。

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

3.4 ?原型設(shè)計(jì)（Prototype）

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

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

4 ?設(shè)計(jì)實(shí)例分析

4.1 ?產(chǎn)品概要

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

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

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

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

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

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

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

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

4.3 ?BBS案例的接口設(shè)計(jì)

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

這個(gè)列表可以為日后的接口開(kāi)發(fā)工作提供實(shí)際參照標(biāo)準(zhǔn)。

4.4 ?BBS案例的結(jié)構(gòu)設(shè)計(jì)

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

BBS系統(tǒng)，在結(jié)構(gòu)圖的第一層，即模塊層來(lái)看，大致可劃分為三：首頁(yè)、帖子和個(gè)人中心，在導(dǎo)航欄中自由切換。

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

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

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

4.5 ?BBS案例的原型設(shè)計(jì)

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

在4.4中所完成的產(chǎn)品結(jié)構(gòu)圖（圖4），本就是以視覺(jué)結(jié)構(gòu)為導(dǎo)向，將產(chǎn)品構(gòu)造逐級(jí)細(xì)分得到的。因此，產(chǎn)品結(jié)構(gòu)圖天然蘊(yùn)含著原型化的基因。在原型設(shè)計(jì)過(guò)程中，也要嚴(yán)格遵循結(jié)構(gòu)圖中所確定的組件結(jié)構(gòu)乃至命名規(guī)范，為日后無(wú)縫過(guò)渡到UI開(kāi)發(fā)打好基礎(chǔ)。

以摹客為例，在完成原型設(shè)計(jì)后，單擊左上樹(shù)狀圖中的【腦圖編輯模式】按鈕，可顯示腦圖如圖5。其構(gòu)造與結(jié)構(gòu)圖完全一致。

5 ?結(jié)語(yǔ)

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

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

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

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

參考文獻(xiàn)

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

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

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

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

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

[6] 黎永良， 崔杜武. MVC設(shè)計(jì)模式的改進(jìn)與應(yīng)用[J]. 計(jì)算機(jī)工程， 2005（09）： 96-97+212.

[7] 劉紅霞， 陸文迪. 改進(jìn)的MVC設(shè)計(jì)模式的研究與應(yīng)用[J]. 計(jì)算機(jī)工程與科學(xué)， 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框架的開(kāi)發(fā)[J]. 電腦編程技巧與維護(hù)， 2016（23）： 5-8.

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

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