业务请求的处理方法及装置、存储介质以及电子设备与流程

1.本公开实施例涉及软件开发技术领域，具体而言，涉及一种业务请求的处理方法、业务请求的处理装置、计算机可读存储介质以及电子设备。


背景技术：

2.目前，spring(开源应用框架)、spring boot(开源的轻量级框架)是java(面向对象编程语言)后端开发领域事实上的标准，许多服务端应用都是基于spring框架进行开发的；其中，在实际开发中，经常需要通过http(hypertext transfer protocol，超文本传输协议)接口与前端页面或者移动端应用进行交互；而交互过程中，前后端通常会定义一个统一的数据报文格式，后端所有的返回报文都必须符合该格式，否则前端无法进行解析。
3.为了解决上述问题，现有技术通过在前后端约定一个统一的数据报文格式，然后基于该统一的数据报文格式对操作结果进行手动封装，进而得到响应报文。
4.但是，上述方案存在如下缺陷：对于每个需要返回约定报文格式的接口，都需要手动封装，如果有错误码，还需要进行填充，存在大量的重复性劳动，进而使得响应报文的生成效率较低。
5.因此，需要提供一种新的业务请求的处理方法及装置。
6.需要说明的是，在上述背景技术部分发明的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素：

7.本公开的目的在于提供一种业务请求的处理方法、业务请求的处理装置、计算机可读存储介质以及电子设备，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的响应报文的生成效率较低的问题。
8.根据本公开的一个方面，提供一种业务请求的处理方法，包括：
9.接收客户端发送的业务请求，响应于所述业务请求执行与所述业务请求对应的业务处理得到当前业务处理结果；
10.基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理，并基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理；
11.基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文；
12.将所述响应报文发送至所述客户端，以使得所述客户端对所述响应报文进行展示。
13.在本公开的一种示例性实施例中，在接收客户端发送的业务请求之前，所述业务请求的处理方法还包括：
14.基于预设的注解导入参数，导入全局配置注解；
15.利用所述全局配置注解，开启所述参数校验结果处理器、全局异常处理器以及统一报文封装处理器。
16.在本公开的一种示例性实施例中，接收客户端发送的业务请求，响应于所述业务请求执行与所述业务请求对应的业务处理得到当前业务处理结果，包括：
17.利用spring/spring boot框架中所包括的控制层接收所述客户端发送的业务请求，响应于所述业务请求调用spring/spring boot框架中所包括的业务逻辑层；
18.所述业务逻辑层根据所述业务请求中所包括的业务属性信息生成查询请求，并调用所述spring/spring boot框架中所包括的数据持久层；
19.所述数据持久层从所述spring/spring boot框架中所包括的数据库实体层中获取所述当前业务处理结果，并将所述当前业务处理结果反馈至所述业务逻辑层，经由所述业务逻辑层反馈至所述控制层。
20.在本公开的一种示例性实施例中，基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理，包括：
21.基于预设的参数校验结果处理器判断所述当前业务处理结果中所包括的参数校验结果是否存在参数异常；
22.在确定存在参数异常时，根据参数异常的异常类别以及预设的第一映射关系，获取与所述异常类别对应的第一默认错误码；
23.将所述第一默认错误码封装置所述当前业务处理结果中，以完成所述第一预设处理。
24.在本公开的一种示例性实施例中，基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理，包括：
25.基于预设的全局异常处理器获取异常处理注解，并利用所述异常处理注解提取所述当前业务处理结果中所包括的异常错误码；
26.在确定所述异常错误码为空时，根据预设的第二映射关系获取在异常错误码为空时的第二默认错误码，并将所述第二默认错误码填充至所述当前业务处理结果中，以完成所述第二预设处理；
27.在确定所述异常错误码非空时，获取所述异常处理注解中的目标错误码以及与所述目标错误码对应的错误提示，并将所述目标错误码以及所述错误提示填充至所述当前业务处理结果中，以完成所述第二预设处理。
28.在本公开的一种示例性实施例中，基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文，包括：
29.基于预设的统一报文封装处理器判断经过第一预设处理以及第二预设处理后的当前业务处理结果中所包括的方法的返回类型是否为空；
30.若返回类型为空，则根据经过第一预设处理以及第二预设处理后的当前业务处理结果创建默认的成功统一报文对象；
31.根据所述成功统一报文对象生成与所述业务请求对应的响应报文。
32.在本公开的一种示例性实施例中，所述业务请求的处理方法还包括：
33.若所述返回类型非空，则判断所述方法的返回值是否为空；
34.如果所述返回值为空，则根据经过第一预设处理以及第二预设处理后的当前业务处理结果创建默认的成功统一报文对象，根据所述成功统一报文对象生成与所述业务请求对应的响应报文；
35.如果所述返回值非空且所述返回值非预设的统一报文定义类，则将所述返回值封装为所述统一报文定义类的对象，并根据所述统一报文定义类的对象生成与所述业务请求对应的响应报文。
36.根据本公开的一个方面，提供一种业务请求的处理装置，包括：
37.业务处理执行模块，用于接收客户端发送的业务请求，响应于所述业务请求执行与所述业务请求对应的业务处理得到当前业务处理结果；
38.业务处理结果处理模块，用于基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理，并基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理；
39.业务处理结果封装模块，用于基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文；
40.响应报文发送模块，用于将所述响应报文发送至所述客户端，以使得所述客户端对所述响应报文进行展示。
41.根据本公开的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的业务请求的处理方法。
42.根据本公开的一个方面，提供一种电子设备，包括：
43.处理器；以及
44.存储器，用于存储所述处理器的可执行指令；
45.其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的业务请求的处理方法。
46.本公开实施例提供的一种业务请求的处理方法，一方面，通过接收客户端发送的业务请求，响应于业务请求执行与业务请求对应的业务处理得到当前业务处理结果；然后基于预设的参数校验结果处理器对当前业务处理结果中所包括参数校验结果进行第一预设处理，并基于预设的全局异常处理器对当前业务处理结果中所包括的异常错误码进行第二预设处理；再基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与业务请求对应的响应报文；最后将响应报文发送至客户端，以使得客户端对响应报文进行展示，由于可以基于参数校验结果处理器以及全局异常处理器对当前业务处理结果中所包括的参数校验结果以及异常错误码进行处理，并基于统一报文封装处理器对处理后的当前业务处理结果进行统一报文封装进而得到响应报文，实现了响应报文的自动生成，解决了现有技术中由于对于每个需要返回约定报文格式的接口，都需要手动封装，如果有错误码，还需要进行填充，存在大量的重复性劳动，进而使得响应报文的生成效率较低的问题，提高了响应报文的生成效率；另一方面，由于报文封装通过统一报文封装处理器中实现的，避免了现有技术中由于需要在客户端与服务器端之间的接口中实现报文封装进而导致的代码耦合严重的问题，实现了业务处理与视图渲染的解耦。
47.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
48.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
49.图1示意性示出根据本公开示例实施例的一种业务请求的处理方法的流程图。
50.图2示意性示出根据本公开示例实施例的一种spring/spring boot的结构框架图。
51.图3示意性示出根据本公开示例实施例的另一种业务请求的处理方法的流程图。
52.图4示意性示出根据本公开示例实施例的一种基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理的方法流程图。
53.图5示意性示出根据本公开示例实施例的一种基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理的方法流程图。
54.图6示意性示出根据本公开示例实施例的一种基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文的方法流程图。
55.图7示意性示出根据本公开示例实施例的另一种基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文的方法流程图。
56.图8示意性示出根据本公开示例实施例的另一种业务请求的处理方法的流程图。
57.图9示意性示出根据本公开示例实施例的一种业务请求的处理装置的框图。
58.图10示意性示出根据本公开示例实施例的一种用于实现上述业务请求的处理方法的电子设备。
具体实施方式
59.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
60.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功
能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
61.在一些方案中，通常约定的统一的数据报文格式可以如下所示：
[0062][0063]
为了可以将业务请求的执行结果封装成上述统一的响应报文格式，后端开发人员首先需要定义一个实体类，具体可以如下所示：
[0064][0065]
当执行业务请求操作成功后，再将操作结果封装到该实体类的对象中。
[0066]
但是，如果操作过程中出现异常，还需要根据异常类型填充异常错误码和错误信息，之后返回给前端。
[0067]
现有技术条件下接口的代码逻辑结构通常可以如下所示：
[0068][0069]
[0070]
但是，上述方案存在如下缺陷：
[0071]
一方面，开发效率低：仅仅为了统一报文格式，开发者手工创建报文、手工填充结果、手工填充错误码，带来的是开发过程的低效率，完全应该考虑将这些工作单独抽取出来自动完成。
[0072]
另一方面，重复性劳动：每个需要返回约定报文格式的接口，都需要封装，如果有错误码，还需要进行填充。
[0073]
再一方面，代码可读性差：为了返回统一的报文，通常service层的代码都需要返回一个报文对象，这会导致方法返回值的污染，即原本需要返回一个具体业务对象的方法，被迫返回报文封装后的对象，方法的定义也就不再清晰，可读性下降。
[0074]
进一步的，代码耦合、职责混乱：返回的报文和错误码的封装，即将执行的结果封装为约定的报文，或者将异常错误转化成错误码返回给调用方，这些都是属于视图层代码的职责，目前全部都在业务代码里面手工完成，造成代码耦合严重，且代码职责混乱不清。
[0075]
更进一步的，冗长的参数校验提示：当接口入参需要校验时，往往需要手工进行非空判定等校验，需要校验的参数越多，用于校验的代码越冗长，其实这些代码都不是核心业务逻辑，应该想办法交给框架进行校验。
[0076]
最后，混乱的异常处理体系：现有技术在每个接口进行异常捕获，然后根据不同的异常，封装异常码到上述的result、commonresult中，满篇的try
……
catch既显得代码冗余，也影响开发效率，还影响代码的可读性。对外提供的api，处理业务逻辑时发生了异常，不能直接给调用方返回异常堆栈信息，而是要返回这个异常对应的错误码，便于双方开发人员对接。异常类并没有和异常错误码进行关联，在抛出异常时，需要到枚举类、到定义类中找到异常对应的异常码，既容易出错，也非常低效。
[0077]
基于此，本示例实施方式中首先提供了一种业务请求的处理方法，该方法可以运行于spring/spring boot框架所在的服务器、服务器集群或云服务器等；当然，本领域技术人员也可以根据需求在其他平台运行本公开的方法，本示例性实施例中对此不做特殊限定。参考图1所示，该业务请求的处理方法可以包括以下步骤：
[0078]
步骤s110.接收客户端发送的业务请求，响应于所述业务请求执行与所述业务请求对应的业务处理得到当前业务处理结果；
[0079]
步骤s120.基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理，并基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理；
[0080]
步骤s130.基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文；
[0081]
步骤s140.将所述响应报文发送至所述客户端，以使得所述客户端对所述响应报文进行展示。
[0082]
上述业务请求的处理方法中，一方面，通过接收客户端发送的业务请求，响应于业务请求执行与业务请求对应的业务处理得到当前业务处理结果；然后基于预设的参数校验结果处理器对当前业务处理结果中所包括参数校验结果进行第一预设处理，并基于预设的全局异常处理器对当前业务处理结果中所包括的异常错误码进行第二预设处理；再基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果
进行统一报文封装，得到与业务请求对应的响应报文；最后将响应报文发送至客户端，以使得客户端对响应报文进行展示，由于可以基于参数校验结果处理器以及全局异常处理器对当前业务处理结果中所包括的参数校验结果以及异常错误码进行处理，并基于统一报文封装处理器对处理后的当前业务处理结果进行统一报文封装进而得到响应报文，实现了响应报文的自动生成，解决了现有技术中由于对于每个需要返回约定报文格式的接口，都需要手动封装，如果有错误码，还需要进行填充，存在大量的重复性劳动，进而使得响应报文的生成效率较低的问题，提高了响应报文的生成效率；另一方面，由于报文封装通过统一报文封装处理器中实现的，避免了现有技术中由于需要在客户端与服务器端之间的接口中实现报文封装进而导致的代码耦合严重的问题，实现了业务处理与视图渲染的解耦。
[0083]
以下，将结合附图对本公开示例实施例业务请求的处理方法进行详细的解释以及说明。
[0084]
首先，对本公开示例实施例的spring/spring boot框架进行解释以及说明。参考图2所示，spring/spring boot框架可以包括model(数据库实体)层201、dao(数据持久)层202、service(业务逻辑)层203以及controller(控制)层204。
[0085]
其中，model层为数据库实体层，也被称为entity层，pojo层；其中，一般数据库一张表对应一个实体类，类属性与表字段一一对应；
[0086]
dao层为数据持久层，也被称为mapper层；dao层的作用为访问数据库，向数据库发送sql语句，完成数据的增删改查任务；
[0087]
service层为业务逻辑层，其作用是完成功能设计；service层调用dao层接口，接收dao层返回的数据，完成项目的基本功能设计；service可以包括接口和实现类；
[0088]
controller层为控制层，其功能为请求和响应控制，controller层负责前后端交互，接受前端请求，调用service层，接收service层返回的数据，最后返回具体的页面和数据到客户端。
[0089]
其次，为了可以实现响应报文的自动生成，还需要开启组件。具体的，参考图3所示，该业务请求的处理方法还可以包括：
[0090]
步骤s310，基于预设的注解导入参数，导入全局配置注解；
[0091]
步骤s320，利用所述全局配置注解，开启所述参数校验结果处理器、全局异常处理器以及统一报文封装处理器。
[0092]
以下，将对步骤s310以及步骤s320进行解释以及说明。具体的，在spring boot中，提供了@import注解(也即预设的注解导入参数)，可以用来导入其他配置。定义了@enableglobalresulthandler(全局配置)注解作为组件开关之后，通过@import注解，导入被@configuration注解修饰的配置类。配置类中对需要的bean进行了初始化。
[0093]
@enableglobalresulthandler注解内容如下：
[0094]
@target({elementtype.type})
[0095]
@retention(retentionpolicy.runtime)
[0096]
@documented
[0097]
@inherited
[0098]
@import(globalresulthandlerautoconfig.class)
[0099]
public@interface enableglobalresulthandler{
[0100]
}
[0101]
引入的globalresulthandlerautoconfig配置类为：
[0102]
@configuration
[0103]
@enableconfigurationproperties(globalresulthandlerconfigproperties.class)
[0104]
pulic class globalresulthandlerautoconfig{
[0105]
globalresulthandlerautoconfig配置文件中初始化默认缺省的配置，具体可以如下所示：
[0106][0107]
如此，即可通过注解一键启用组件。
[0108]
以下，结合图2以及图3对步骤s110
‑
步骤s140进行解释以及说明。
[0109]
在本公开示例实施例的一种业务请求的处理方法中：
[0110]
在步骤s110中，接收客户端发送的业务请求，响应于所述业务请求执行与所述业务请求对应的业务处理得到当前业务处理结果。
[0111]
在本示例实施例中，首先，利用spring/spring boot框架中所包括的controller(控制)层接收所述客户端发送的业务请求，响应于所述业务请求调用spring/spring boot框架中所包括的service(业务逻辑)层；为此，所述service(业务逻辑)层根据所述业务请求中所包括的业务属性信息生成查询请求，并调用所述spring/spring boot框架中所包括的mapper(数据持久)层；最后，所述mapper(数据持久)层从所述spring/spring boot框架中所包括的model(数据库实体)层中获取所述当前业务处理结果，并将所述当前业务处理结果反馈至所述service(业务逻辑)层，经由所述service(业务逻辑)层反馈至所述controller(控制)层。
[0112]
举例来说，当服务端在对某个应用程序开发的过程中，如果需要对该应用程序进
行测试，则可以通过客户端向服务端发送测试请求，然后spring/spring boot框架可以根据该测试请求中所包括的待测试场景，执行相应的业务处理进而得到业务处理结果。例如，当测试场景为测试用户对该应用程序的登录行为时，该待测试场景可以为登录测试场景，该测试场景中可以包括用户登录名、登录密码等等，执行相应的业务处理，即可以为判断该登录名和/或登录密码是否正确等等，具体可以根据实际需要进行限定，本示例对此不做特殊限定。
[0113]
在步骤s120中，基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理，并基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理。
[0114]
在本示例实施例中，首先，基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理，具体的可以包括：首先，基于预设的参数校验结果处理器判断所述当前业务处理结果中所包括的参数校验结果是否存在参数异常；其次，在确定存在参数异常时，根据参数异常的异常类别以及预设的第一映射关系，获取与所述异常类别对应的第一默认错误码；最后，将所述第一默认错误码封装置所述当前业务处理结果中，以完成所述第一预设处理。
[0115]
具体的，参考图4所示，第一预设处理的具体过程可以包括以下步骤：
[0116]
步骤s401，调用参数校验结果处理器(validtionexceptionadvice)；
[0117]
步骤s402，基于该参数校验结果处理器判断参数校验结果是否存在参数异常；若是，则跳转至步骤s403；若否，则继续下一个参数校验；
[0118]
步骤s403，根据异常类别以及预先设置的第一映射关系获取第一默认错误码；其中，异常类别可以包括验证异常(bindexception)、新增数据报错(constraintviolationexception)以及留言信息过长(methodargumentnot validexception)中的一种或多种；
[0119]
步骤s404，将第一默认错误码封装置当前业务处理结果中。
[0120]
进一步举例来说，继续以上述登录过程为例，在填写登录表单的过程中，如果登录名称为手机号，但其实用户输入的数据为abcd等字符信息，则校验过程出现不合法的数据，则对应的第一默认错误码可以是用户名数据格式错误，或者不存在此用户名等等。
[0121]
进一步的，在本示例实施例中，还需要基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理，具体的可以包括：首先，基于预设的全局异常处理器获取@exceptionmapper(异常处理)注解，并利用所述@exceptionmapper(异常处理)注解提取所述当前业务处理结果中所包括的异常错误码；其次，在确定所述异常错误码为空时，根据预设的第二映射关系获取在异常错误码为空时的第二默认错误码，并将所述第二默认错误码填充至所述当前业务处理结果中，以完成所述第二预设处理；最后，在确定所述异常错误码非空时，获取所述@exceptionmapper(异常处理)注解中的目标错误码以及与所述目标错误码对应的错误提示，并将所述目标错误码以及所述错误提示填充至所述当前业务处理结果中，以完成所述第二预设处理。
[0122]
具体的，参考图5所示，第二预设处理的具体过程可以包括以下步骤：
[0123]
步骤s501，调用全局异常处理器(globalexceptionadivce)；
[0124]
步骤s502，获取exceptionmapper注解；
[0125]
步骤s503，判断异常错误码是否为空；若是，则跳转至步骤s504；若否，则跳转至步骤s505；
[0126]
步骤s504，基于第二映射关系获取第二默认错误码，并将其填充至当前业务处理结果中；
[0127]
步骤s505，获取@exceptionmapper注解中的目标错误码和错误提示，并将目标错误码以及所述错误提示填充至当前业务处理结果中。
[0128]
例如，继续以上述登录过程为例，用户进行登录时，如果密码不对，则抛出异常信息；登录的场景给出错误码，错误信息给前端的返回值例如可以是1400，msg为密码错误；将错误提示展示出来；globalexceptionadivce的具体处理过程为：获取注解，根据自定义的异常信息，判断登录密码是否错误，若出现异常，则捕获该注解；有的异常不属于自定义范围内，若在范围内，填充统一响应对象；若不在范围内，填充默认错误码(默认错误码例如可以为：服务器错误或者网络异常等等，本示例对此不做特殊限定)。
[0129]
在步骤s130中，基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文。
[0130]
在本示例实施例中，首先，基于预设的统一报文封装处理器判断经过第一预设处理以及第二预设处理后的当前业务处理结果中所包括的方法的返回类型是否为空；其次，若返回类型为空，则根据经过第一预设处理以及第二预设处理后的当前业务处理结果创建默认的success(成功)统一报文对象；最后，根据所述success(成功)统一报文对象生成与所述业务请求对应的响应报文。
[0131]
进一步的，在本示例实施例中，若所述返回类型非空，则判断所述方法的返回值是否为空；如果所述返回值为空，则根据经过第一预设处理以及第二预设处理后的当前业务处理结果创建默认的success(成功)统一报文对象，根据所述success(成功)统一报文对象生成与所述业务请求对应的响应报文；如果所述返回值非空且所述返回值非预设的统一报文定义类，则将所述返回值封装为所述统一报文定义类的对象，并根据所述统一报文定义类的对象生成与所述业务请求对应的响应报文。
[0132]
以下，结合图6以及图7对步骤s130进行进一步的解释以及说明。
[0133]
首先，参考图6所示：
[0134]
步骤s601，调用统一报文封装处理器(voidresponsebodyadvice)；
[0135]
步骤s602，判断方法的返回类型是否为空(void)；若是，则跳转至步骤s603；若否，则跳转至步骤s701；
[0136]
步骤s603，创建默认的success统一报文对象，并生成响应报文。
[0137]
其次，参考图7所示：
[0138]
步骤s701，调用统一报文封装处理器(notvoidresponsebodyadvice)；
[0139]
步骤s702，判断方法的返回类型是否非空(notvoid)；若是，跳转至步骤s703；若否，则继续下一个方法；
[0140]
步骤s703，判断方法的返回值是否为空(null)；若是，则跳转至步骤s704；若否，则跳转至步骤s705；
[0141]
步骤s704，创建默认的success统一报文对象，并生成响应报文；
[0142]
步骤s705，将返回值封装为统一报文定义类的对象，并生成响应报文。
[0143]
在步骤s140中，将所述响应报文发送至所述客户端，以使得所述客户端对所述响应报文进行展示。
[0144]
具体的，当客户端对响应报文展示以后，用户和/或测试人员可以根据该响应报文判断测试是否通过，如果未通过，还可以看到测试失败的原因，进而根据失败原因进行调试。通过该方法，大大的提高了开发效率。
[0145]
以下，结合图8对本公开示例实施例业务请求的处理方法进行进一步的解释以及说明。参考图8所示，该业务请求的处理方法可以包括以下步骤：
[0146]
步骤s810，开启注解，并通过注解对统一报文封装与异常错误码匹配组件进行配置；
[0147]
步骤s820，controller接收客户端发送的业务请求，并调用业务处理service层执行业务处理得到当前业务处理结果；
[0148]
步骤s830，controller利用统一报文封装与异常错误码匹配组件对当前业务处理结果进行封装，得到响应报文；
[0149]
步骤s840，controller将响应报文发送至客户端，以使得客户端对响应报文进行展示。
[0150]
本公开示例实施例提供的业务请求的处理方法，至少具有以下优点：
[0151]
一方面，提高开发效率：通过一个注解，开启全局的自动返回报文封装和异常错误码匹配，之后每个接口不需要再手工创建成功报文对象或者填充错误码，极大地提高了开发效率。
[0152]
另一方面，减少重复性劳动：注解开启后，组件自动进行报文封装，不需要手工参与，也就不需要重复地在每个接口封装返回对象。
[0153]
再一方面，提高代码可读性：在接口中只需要写业务相关的代码逻辑，返回报文的封装已经完全由组件完成，代码可读性很高。
[0154]
进一步的，代码解耦：接口中只处理业务逻辑，返回报文的封装已经完全由组件完成，完成了业务处理与视图渲染的解耦，代码职责清晰。
[0155]
更进一步的，整合现有的参数校验方式：通过整合hibernate validator参数校验框架，无需额外编码，即可进行参数校验和提示返回
[0156]
最后，提供简单可行的异常错误码体系：通过@exceptionmapper注解，在自定义异常时，将异常码定义好，抛出异常时组件自动填充错误码。异常定义如下图：
[0157]
@exceptionmapper(code＝1404，msg＝“not found！”)
[0158]
public static class notfoundexception extends runtimeexception{}
[0159]
本公开还提供了一种业务请求的处理装置。参考图9所示，该业务请求的处理装置可以包括业务处理执行模块910、业务处理结果处理模块920、业务处理结果封装模块930以及响应报文发送模块940。其中：
[0160]
业务处理执行模块910可以用于接收客户端发送的业务请求，响应于所述业务请求执行与所述业务请求对应的业务处理得到当前业务处理结果；
[0161]
业务处理结果处理模块920可以用于基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理，并基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理；
[0162]
业务处理结果封装模块930可以用于基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文；
[0163]
响应报文发送模块940可以用于将所述响应报文发送至所述客户端，以使得所述客户端对所述响应报文进行展示。
[0164]
在本公开的一种示例性实施例中，所述业务请求的处理装置还包括：
[0165]
注解导入模块，可以用于基于预设的注解导入参数，导入全局配置注解；
[0166]
处理开启模块，可以用于利用所述全局配置注解，开启所述参数校验结果处理器、全局异常处理器以及统一报文封装处理器。
[0167]
在本公开的一种示例性实施例中，所述业务处理执行模块还可以被配置于：
[0168]
利用spring/spring boot框架中所包括的控制层接收所述客户端发送的业务请求，响应于所述业务请求调用spring/spring boot框架中所包括的业务逻辑层；
[0169]
所述业务逻辑层根据所述业务请求中所包括的业务属性信息生成查询请求，并调用所述spring/spring boot框架中所包括的数据持久层；
[0170]
所述数据持久层从所述spring/spring boot框架中所包括的数据库实体层中获取所述当前业务处理结果，并将所述当前业务处理结果反馈至所述业务逻辑层，经由所述业务逻辑层反馈至所述控制层。
[0171]
在本公开的一种示例性实施例中，所述业务处理结果处理模块还可以被配置于：
[0172]
基于预设的参数校验结果处理器判断所述当前业务处理结果中所包括的参数校验结果是否存在参数异常；
[0173]
在确定存在参数异常时，根据参数异常的异常类别以及预设的第一映射关系，获取与所述异常类别对应的第一默认错误码；
[0174]
将所述第一默认错误码封装置所述当前业务处理结果中，以完成所述第一预设处理。
[0175]
在本公开的一种示例性实施例中，所述业务处理结果处理模块还可以被配置于：
[0176]
基于预设的全局异常处理器获取异常处理注解，并利用所述异常处理注解提取所述当前业务处理结果中所包括的异常错误码；
[0177]
在确定所述异常错误码为空时，根据预设的第二映射关系获取在异常错误码为空时的第二默认错误码，并将所述第二默认错误码填充至所述当前业务处理结果中，以完成所述第二预设处理；
[0178]
在确定所述异常错误码非空时，获取所述异常处理注解中的目标错误码以及与所述目标错误码对应的错误提示，并将所述目标错误码以及所述错误提示填充至所述当前业务处理结果中，以完成所述第二预设处理。
[0179]
在本公开的一种示例性实施例中，所述业务处理结果封装模块还可以被配置于：
[0180]
基于预设的统一报文封装处理器判断经过第一预设处理以及第二预设处理后的当前业务处理结果中所包括的方法的返回类型是否为空；
[0181]
若返回类型为空，则根据经过第一预设处理以及第二预设处理后的当前业务处理结果创建默认的成功统一报文对象；
[0182]
根据所述成功统一报文对象生成与所述业务请求对应的响应报文。
[0183]
在本公开的一种示例性实施例中，所述业务处理结果封装模块还可以被配置于：
[0184]
若所述返回类型非空，则判断所述方法的返回值是否为空；
[0185]
如果所述返回值为空，则根据经过第一预设处理以及第二预设处理后的当前业务处理结果创建默认的成功统一报文对象，根据所述成功统一报文对象生成与所述业务请求对应的响应报文；
[0186]
如果所述返回值非空且所述返回值非预设的统一报文定义类，则将所述返回值封装为所述统一报文定义类的对象，并根据所述统一报文定义类的对象生成与所述业务请求对应的响应报文。
[0187]
上述业务请求的处理装置中各模块的具体细节已经在对应的业务请求的处理方法中进行了详细的描述，因此此处不再赘述。
[0188]
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
[0189]
此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
[0190]
在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。
[0191]
所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。
[0192]
下面参照图10来描述根据本公开的这种实施方式的电子设备1000。图10显示的电子设备1000仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
[0193]
如图10所示，电子设备1000以通用计算设备的形式表现。电子设备1000的组件可以包括但不限于：上述至少一个处理单元1010、上述至少一个存储单元1020、连接不同系统组件(包括存储单元1020和处理单元1010)的总线1030以及显示单元1040。
[0194]
其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1010执行，使得所述处理单元1010执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。例如，所述处理单元1010可以执行如图1中所示的步骤s110：接收客户端发送的业务请求，响应于所述业务请求执行与所述业务请求对应的业务处理得到当前业务处理结果；步骤s120：基于预设的参数校验结果处理器对所述当前业务处理结果中所包括参数校验结果进行第一预设处理，并基于预设的全局异常处理器对所述当前业务处理结果中所包括的异常错误码进行第二预设处理；步骤s130：基于预设的统一报文封装处理器对经过第一预设处理以及第二预设处理后的当前业务处理结果进行统一报文封装，得到与所述业务请求对应的响应报文；步骤s140：将所述响应报文发送至所述客户端，以使得所述客户端对所述响应报文进行展示。
[0195]
存储单元1020可以包括易失性存储单元形式的可读介质，例如随机存取存储单元
(ram)10201和/或高速缓存存储单元10202，还可以进一步包括只读存储单元(rom)10203。
[0196]
存储单元1020还可以包括具有一组(至少一个)程序模块10205的程序/实用工具10204，这样的程序模块10205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
[0197]
总线1030可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
[0198]
电子设备1000也可以与一个或多个外部设备1100(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1000交互的设备通信，和/或与使得该电子设备1000能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口1050进行。并且，电子设备1000还可以通过网络适配器1060与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器1060通过总线1030与电子设备1000的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1000使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
[0199]
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd
‑
rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。
[0200]
在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。
[0201]
根据本公开的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(cd
‑
rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
[0202]
所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
[0203]
计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、
光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
[0204]
可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。
[0205]
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
[0206]
此外，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。
[0207]
本领域技术人员在考虑说明书及实践这里发明的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未发明的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。