标识符规范化

通常在顺利完成USB结构设计后，就能开始标识符了。而对标识符而言，制订标识符规范化是最简单且有效率的清查方式，如果合作开发项目组严格遵守一些准则展开合作开发，就能非常大某种程度上防止纷乱。后端插件的标识符规范化通常考量下列两个各方面：

·产品目录内部结构，需明晰产品目录方式论；

·管制解释器层次，以减少标识符纷乱度；

·释放出来公用组件，提高标识符F83E43Se度；

·严重错误监督机制。

特别注意：下列的具体内容重新命名或准则不是惟一，能依照偏爱和详细情况TNUMBERA0512Ci。本拍子的范例都以Java做为合作开发词汇，以Spring Boot做为此基础构架。

1.产品目录内部结构

以Spring Boot为例，当如上所述化工程建设后，产品目录内部结构如图4.43。其中，须要重视的多于三部份，依次是内部结构辅助工具命令行、后端插件命令行和标识符。

图4.43 如上所述的Spring Boot工程建设

在如上所述的Spring Boot工程建设里，标识符部份除Application.java和ServletInitializer.java两个引导文件之外，没有其它标识符。由此可见，后端插件的标识符内部结构只不过是对外开放的，合作开发人员能依照对个人偏爱总体规划标识符产品目录内部结构。不过，Spring有关构架（Spring Boot、Spring MVC等）提供更多了一种多层思想，绝大多数采用Spring有关构架的合作开发人员都是依照这个多层价值观展开合作开发的。因此，标识符内部结构最合适遵从Spring有关构架的多层价值观。

Spring有关构架建议将标识符分成三层：Controller层、Service层和Dao层，如图4.44所示。Controller层负责管理业务调度（调用Service层），也是USB函数的入口；Service层负责实现业务功能，通常会做一些算法方式论和调用Dao层；Dao层负责与数据库展开交互。

图4.44 Controller、Service和Dao三层内部结构

提倡把URL的路径分成三层，即组件、子组件和具体内容资源。

在实际的Spring Boot工程建设产品目录内部结构里，组件指的是工程建设名（.war包的名字）；子组件指的是Controller的标识，每个子组件应该有单独的Controller.java文件（例如图4.44中的xxController.java、yyController.java）；具体内容资源指的是对应函数的标识（“具体内容资源标识”加“请求方式”才能惟一标识某个特定USB函数）。

以修改用户名的USB（URL：/users/settings/username，请求方式PUT）为例，USB对应的入口函数如标识符4.21所示，其中，/settings为子组件标识，/username为具体内容资源标识，PUT标记的是请求方式。

标识符4.21　修改用户名USB对应的入口函数

package com.example.users.controller;

import …

@Controller

@RequestMapping(“/settings”) //子组件标识

public class SettingsController {

…

//修改用户名USB的入口函数

//具体内容资源和请求方式标识

@RequestMapping(value=”/username”, method=RequestMethod.PUT)

@ResponseBody

public JSONObject UpdateUserName(@RequestBody String requestParam) {

…

}

//其它USB的入口函数，如修改密码（URL为/users/settings/password，请求方式为PUT）

@RequestMapping(value=”/password”, method=RequestMethod.PUT)

@ResponseBody

public JSONObject UpdatePassword(@RequestBody String requestParam) {

…

}

…

}

综上，基本的后端插件工程建设（以Spring Boot为此基础构架）的产品目录内部结构及其产品目录方式论如图4.45所示。

图4.45 基本产品目录内部结构及其产品目录方式论

2.管制解释器层次

通常情况下，采用Spring Boot做为此基础构架的后端应用程序都会把标识符部份按Controller、Service和Dao多层（如图4.45所示）。大部份人都认为，如果标识符依照这三层多层，就不会出现太大的纷乱。但实际上，仅凭这三个多层，并不能匀称化标识符。虽然这三个多层能让标识符在整体上有一个流水处理的感觉（如图4.44所示），但是在实际标识符中，这三层的约束和分工都相当模糊，以至于程序内部的调用关系非常大概率会出现十分纷乱的局面，如图4.46所示。

图4.46 混乱的内部调用关系

一个小型中文网站系统，后端插件须要随着中文网站的运营不断做调整，当出现以上这种纷乱的调用关系时，程序的内部会变成一张“蜘蛛网”，后端插件的维护和扩展都变得十分艰难，即使是原来的合作开发人员，也须要花很长时间去梳理。而这种纷乱，并不是完备的注释和文档就能解决的，因为即使是最完备的注释和文档也不可能描述所有的标识符细节和调用关系。

说明：一个软件的质量，除功能性、效率性和稳定性之外，更关键的是其维护和扩展的难度。而维护和扩展难度只不过指的是标识符编写方式论，好的标识符编写方式论应该是内部结构明显、调用关系整洁的。

后端插件是多个USB的集合，也就是多个小程序的集合。而单个USB所须要实现的功能通常是简单的，对应的标识符也是很简短的，不存在过于复杂的方式论。也就是说，后端插件的复杂性不在于其功能，而在于其包含多个USB。因此，横向切分后端插件只不过并不能很好地匀称标识符，而是应该先垂直切分每个USB标识符（每个USB的标识符完全独立），再横向切分每个USB的内部标识符，

如图4.47所示。这样的话，就不会出现“蜘蛛网”式的调用关系，无论是增加USB还是修改USB标识符，都会变得很简单，也不会存在修改了一个USB的标识符却影响了五六个USB的情况。

图4.47 垂直切分后端插件

垂直切分只不过就是管制解释器层次，一个USB在Controller层和Service层各多于一个专属函数（Dao层能有多个函数，但是最合适不要和其它USB产生关联），USB标识符不允许调用其它USB的专属函数，即以一种垂直的方式顺利完成USB功能，如图4.48所示。其中Controller.java、Service.java和Dao.java文件也应该尽量垂直对应。

图4.48 垂直的内部调用关系

特别注意：一些时候，共用函数是不可防止的，特别是Dao层，这些时候能适当地冲破一下垂直调用的准则，但不能因为这些特殊情况而放宽整个编写标识符的准则。

3.公用组件

在管制函数调用层次后，在便于标识符修改和标识符理解的同时，自然也会增加标识符的冗余某种程度。因此，在管制解释器层次后，须要释放出来公用组件，以达到减少标识符冗余度的目的。而对公用组件的抽取，须要对USB做的“重复事情”有一个清晰的认识。在Controller层，USB标识符会做一些前期工作，如用户权限认证、必要参数检查、可选参数填充等；在Service层，USB标识符会做一些业务功能的操作，如数据库调用、第三方应用调用等。那么，对这些“重复事情”，能将其做为公用组件释放出来出来，USB标识符中能通过传入不同的参数来采用这些组件功能，如图4.49所示。

图4.49 释放出来公用组件

在图4.49中，把数据库操作释放出来成了一个公用组件，而在前面的介绍里，数据库操作应该放到Dao层。在中小型中文网站当中，数据库通常都是中文网站的惟一核心，在这些以数据库为核心的中文网站系统当中，后端插件只不过就是做为前端采用数据库的桥梁，绝绝大多数的Service层标识符也是为了操作数据库。因此，在中小型中文网站当中，把数据库操作放在Dao层确实会让后端插件在整体上有一个清晰的方式论。

但是，在小型中文网站中，数据库就不一定是中文网站的惟一核心了，小型中文网站的后端应用程除要操作数据库之外，还须要整合其它插件（如视频转码服务、非关系型数据库等）。从Service层的标识符来看，数据库的采用只是其功能的一部份，而不是Service层的惟一目标。因此，在小型中文网站当中，把数据库操作释放出来成其中一个公用组件更合理一些。

不过，数据库操作还是放在Dao层比较好，因为绝大多数的合作开发人员还是习惯把数据库操作放在Dao层里。在释放出来公用组件后，USB标识符能写成流水线的模式，从而能让人一目了然：第一步做了什么，第二步做了什么。而且如果这些组件做得足够好的话，能直接在多个项目中采用，让合作开发人员更注重USB流程，而省去很多写冗余标识符的时间。增加公用组件后，后端插件的产品目录内部结构如图4.50所示。

说明：释放出来公用组件在实际标识符中就是创建类或创建函数，具体内容方式和准则可依照项目组偏爱TNUMBERA0512Ci。

图4.50 释放出来公用组件后的产品目录内部结构及产品目录方式论

4.严重错误监督机制

严重错误监督机制是一个经常被忽略，但却特别重要的点。在4.3.1节USB结构设计中也强调，返回参数中须要带有处理结果标识符及其描述。

在实现了公用组件释放出来后，能在调用组件后判断处理的结果，如果发生严重错误的话，就直接返回严重错误结果，不再展开后续步骤的处理，如图4.51所示。

严重错误监督机制在流水线式的流程中能起到“保险丝”的作用，一旦上一个步骤发生严重错误，下一个步骤就不会被执行，这样能保证每个步骤的健康运行。严重错误提示也能初步定位问题发生的位置，能省去很多排查的工作量。通常而言，错误提示不须要太具体内容，如“缺少必要参数”的严重错误提示，不须要精确到缺少了哪些参数。