论文部分内容阅读
摘 要： 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.
关键词： 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.