CN114385116A - 一种业务的实现方法和系统 - Google Patents

Abstract

本发明公开了一种业务的实现方法和系统，涉及Web应用程序领域。该方法包括：通过提取业务请求的业务编号，解析配置文件和业务编号，在解析结果中获取与业务编号对应的业务类和实现方法，解析出业务类的全类名和实现方法的方法名，通过反射动态调用方法调用全类名和方法名，来获得实现方法的类实例，执行类实例，根据执行结果响应预设业务，通过本方案的方法全局使用一个核心控制器coreAction，一次开发全局使用，对开发人员只需实现业务逻辑，不需要再创建过多的控制器，降低开发人员的工作量、降低代码冗余，便于代码维护。

Description

一种业务的实现方法和系统

技术领域

本发明涉及Web应用程序领域，尤其涉及一种业务的实现方法和系统。

背景技术

Spring MVC是一个基于动作的MVC框架。在该框架中用户的每一个请求都声明了一个需要执行的动作。而这主要是通过将每个请求URI映射到一个可执行的方法来实现。

在目前的实现方式中，针对不同的业务请求还需要实现特定的控制器动作，增加开发人员的工作量、加大代码冗余，需要重复创建控制器。

发明内容

本发明所要解决的技术问题是针对现有技术的不足，提供一种业务的实现方法和系统。

本发明解决上述技术问题的技术方案如下：

一种业务的实现方法，包括:

获取业务请求，并提取与所述业务请求对应的业务编号；

解析配置文件获取与所述业务编号对应的业务类和实现方法；

解析出所述业务类的全类名和所述实现方法的方法名；

通过反射动态调用方法调用所述全类名和所述方法名，来获得所述实现方法的类实例；

执行所述类实例，根据执行结果响应所述预设业务。

本发明的有益效果是：本申请方案通过提取业务请求的业务编号，解析配置文件和业务编号，在解析结果中获取与业务编号对应的业务类和实现方法，解析出业务类的全类名和实现方法的方法名，通过反射动态调用方法调用全类名和方法名，来获得实现方法的类实例，执行类实例，根据执行结果响应预设业务，通过本方案的方法全局使用一个核心控制器coreAction，一次开发全局使用，对开发人员只需实现业务逻辑，不需要再创建过多的控制器，降低开发人员的工作量、降低代码冗余，便于代码维护。

进一步地，所述根据所述业务编号在解析结果中获取与所述业务编号对应的业务类和实现方法之前还包括：

根据每个业务类型分别建立业务类和实现方法的映射关系，并设置每个业务类型的业务编号。采用上述进一步方案的有益效果是：本方案通过根据业务编码分别建立业务类和实现方法的映射关系，对于用户请求使用唯一的url路径coreAction，通过设置请求参数requestId便可以成功调用业务逻辑实现，方便易用。

进一步地，所述解析配置文件之前还包括：

获取每个业务类对应的请求路径，以及每个实现方法对应的业务逻辑；

根据每个业务类和每个实现方法的映射关系，获取每个请求路径和每个业务逻辑的映射关系，根据每个请求路径和每个业务逻辑的映射关系构建所述配置文件。

采用上述进一步方案的有益效果是：本方案通过构建配置文件，对业务接口的管理只需要维护xml文件，就可以实现接口和业务实现的关系管理。

进一步地，还包括：

将所述执行结果封装为响应数据模型；

通过控制器解析所述响应数据模型，根据解析结果更新视图层数据。

采用上述进一步方案的有益效果是：本方案根据解析结果更新视图层数据，实现在数据变化时更新视图，使得视图与模型分离。

进一步地，还包括：

根据预设业务发起业务请求，并发送相应的业务编号。

本发明解决上述技术问题的另一种技术方案如下：

一种业务的实现系统，包括：提取模块、配置文件解析模块、业务解析模块、调用模块和执行模块；

所述提取模块用于获取业务请求，并提取与所述业务请求对应的业务编号；

所述配置文件解析模块用于解析配置文件获取与所述业务编号对应的业务类和实现方法；

所述业务解析模块用于解析出所述业务类的全类名和所述实现方法的方法名；

所述调用模块用于通过反射动态调用方法调用所述全类名和所述方法名，来获得所述实现方法的类实例；

所述执行模块用于执行所述类实例，根据执行结果响应所述预设业务。

本发明的有益效果是：本申请方案通过提取业务请求的业务编号，解析配置文件和业务编号，在解析结果中获取与业务编号对应的业务类和实现方法，解析出业务类的全类名和实现方法的方法名，通过反射动态调用方法调用全类名和方法名，来获得实现方法的类实例，执行类实例，根据执行结果响应预设业务，通过本方案的方法全局使用一个核心控制器coreAction，一次开发全局使用，对开发人员只需实现业务逻辑，不需要再创建过多的控制器，降低开发人员的工作量、降低代码冗余，便于代码维护。

进一步地，还包括：业务编码构建模块，用于根据每个业务类型分别建立业务类和实现方法的映射关系，并设置每个业务类型的业务编号。

采用上述进一步方案的有益效果是：本方案通过根据业务编码分别建立业务类和实现方法的映射关系，对于用户请求使用唯一的url路径coreAction，通过设置请求参数requestId便可以成功调用业务逻辑实现，方便易用。

进一步地，还包括：配置模块，用于获取每个业务类对应的请求路径，以及每个实现方法对应的业务逻辑；

根据每个业务类和每个实现方法的映射关系，获取每个请求路径和每个业务逻辑的映射关系，根据每个请求路径和每个业务逻辑的映射关系构建所述配置文件。

采用上述进一步方案的有益效果是：本方案通过构建配置文件，对业务接口的管理只需要维护xml文件，就可以实现接口和业务实现的关系管理。

进一步地，还包括：更新模块，用于将所述执行结果封装为响应数据模型；

通过控制器解析所述响应数据模型，根据解析结果更新视图层数据。

采用上述进一步方案的有益效果是：本方案根据解析结果更新视图层数据，实现在数据变化时更新视图，使得视图与模型分离。

进一步地，所述请求模块用于根据预设业务发起业务请求，并发送相应的业务编号。

本发明附加的方面的优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明实践了解到。

附图说明

图1为本发明的实施例提供的一种业务的实现方法的流程示意图；

图2为本发明的实施例提供的一种业务的实现系统的结构框图；

图3为本发明的其他实施例提供的MVC的关系示意图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实施例只用于解释本发明，并非用于限定本发明的范围。

如图1所示，为本发明实施例提供的一种业务的实现方法，包括:

在某一实施例中，SpringMVC实现了在web开发中，模型-视图-控制器的分离开发。在视图层，开发者关注的数据的呈现，在模型层，开发者关注的是数据的输入输出的结构。通过控制器层，将模型和视图进行数据的关联以及逻辑的绑定；在另一实施例中，MVC的关系示意图如图3所示，Model(模型)：模型代表一个存取数据的对象或POJO。它也可以带有逻辑，在数据变化时更新控制器；View(视图)：视图代表模型包含的数据的可视化；Controller(控制器)：控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图，使得视图与模型分离。

S1，获取业务请求，并提取与业务请求对应的业务编号；

在某一实施例中，在S1之前还可以包括：定义XML配置文件管理业务请求路径url和业务逻辑实现的关系，为每个业务请求定义请求编号，对应相关的业务类和实现方法，程序启动时加载配置文件；在某一实施例中，业务请求是一个动作，业务逻辑是对此动作的实现，例如要查询一个用户，首先要向服务器发起查询用户请求，服务器对此请求执行实现方法。

S2，解析配置文件获取与业务编号对应的业务类和实现方法；

S3，解析出业务类的全类名和实现方法的方法名；

S4，通过反射动态调用方法调用全类名和方法名，来获得实现方法的类实例；

在某一实施例中，获得业务的实现方法的类实例对象可以包括：

Object biz＝SpringContextHolder.getBean(className)；

//获取全类名

String classzName＝biz.getClass().getName()；

//获取类

Class<？>classz＝Class.forName(classzName)；

//封装的请求参数

Class<？>[]paramTypeR＝{RequestEnvelope.class}；

//根据业务方法名称获取业务方法

Method methodR＝classz.getMethod(methodName,paramTypeR)；

//通过反射调用业务方法，传入请求参数requestEnvelope

Object argListR[]＝{requestEnvelope}；

ResponseEnvelope responseEnvelope＝(ResponseEnvelope)methodR.invoke(biz,argListR)；

S5，执行类实例，根据执行结果响应预设业务。

在某一实施例中，基于XML配置文件管理请求路径url和业务逻辑方法的关系，全局请求核心控制器coreAction，通过SpringBean核心容器工具方法，采用反射的方式调用具体的业务实现逻辑，返回逻辑层执行数据。

在另一实施例中，一般的开发过程，针对不同的URL路径，要独立定义一个Controller控制器类，比如LoginControl、LogoutControl、UserControl、OrderControl等等，

或者在Controller控制器类中，扩充一个方法将url路径映射与具体的执行逻辑实例方法进行关联。比如LoginControl：

在优选的方案中，可以包括：只使用一个Controller类，定义一个动作coreAction方法，用户的所有请求url路径都指向/coreAction，相当在开发中我们只需按专利描述步骤实现coreAction，后续业务开发中不需要在实现控制器，只需要实现业务方法，然后在xml中配置业务编号和业务方法的映射关系即可。具体实现方法如下：

本申请方案通过提取业务请求的业务编号，解析配置文件和业务编号，在解析结果中获取与业务编号对应的业务类和实现方法，解析出业务类的全类名和实现方法的方法名，通过反射动态调用方法调用全类名和方法名，来获得实现方法的类实例，执行类实例，根据执行结果响应预设业务，通过本方案的方法全局使用一个核心控制器coreAction，一次开发全局使用，对开发人员只需实现业务逻辑，不需要再创建过多的控制器，降低开发人员的工作量、降低代码冗余，便于代码维护。

优选地，在上述任意实施例中，解析配置文件之前还包括：

获取每个业务类对应的请求路径，以及每个实现方法对应的业务逻辑；

根据每个业务类和每个实现方法的映射关系，获取每个请求路径和每个业务逻辑的映射关系，根据每个请求路径和每个业务逻辑的映射关系构建所述配置文件。在某一实施例中，XML配置定义格式如下：

其中，requestId:交互编号，字符串类型；REQ_开头；V：视图；Q：查询；E：增删改；

class：spring注入的service名称，字符串类型；

method：对应service类的方法名称，字符串类型；

desc：交互描述。

本方案通过构建配置文件，对业务接口的管理只需要维护xml文件，就可以实现接口和业务实现的关系管理。

优选地，在上述任意实施例中，根据业务编号在解析结果中获取与业务编号对应的业务类和实现方法之前还包括：

根据每个业务类型分别建立业务类和实现方法的映射关系，并设置每个业务类型的业务编号。本方案通过根据业务编码分别建立业务类和实现方法的映射关系，对于用户请求使用唯一的url路径coreAction，通过设置请求参数requestId便可以成功调用业务逻辑实现，方便易用。

优选地，在上述任意实施例中，还包括：

将执行结果封装为响应数据模型；

通过控制器解析响应数据模型，根据解析结果更新视图层数据。

采用上述进一步方案的有益效果是：本方案根据解析结果更新视图层数据，实现在数据变化时更新视图，使得视图与模型分离。

优选地，在上述任意实施例中，还包括：

根据预设业务发起业务请求，并发送相应的业务编号。

在某一实施例中，简化SpringMVC控制器的实现业务请求的方法可以包括：

定义XML配置文件管理业务请求路径url和业务逻辑实现的关系，为每个业务请求定义请求编号，对应相关的业务类和实现方法，程序启动时加载配置文件；需要说明的是，业务请求是一个动作，业务逻辑是对此动作的实现，例如要查询一个用户，首先要向服务器发起查询用户请求，服务器对此请求执行实现方法。

用户请求核心控制器coreAction,指定具体的请求编号requestId和参数；

控制器coreAction获取用户请求参数，封装请求参数为统一数据格式对象RequestEnvelope；

控制器coreAction解析XML配置，根据requestId从XML文件中获取请求编号和业务处理方法的关系,解析全类名、方法名；解析全类名、方法名为了在下一步中反射调用业务实现方法时使用；全类名是值包含包路径的java类名称，例如com.gsoft.gimac.services.topologyViewService；方法名是java类中具体的业务实现方法名称；

控制器coreAction通过容器工具SpringContextHolder得到需要执行的类实例，通过反射动态调用方法并传入参数RequestEnvelope；需要说明的是，通过反射去调用具体的业务实现方法，调用的类名、方法名就是上一步中根据requestId从XML中解析到的。

执行请求编号对应的业务逻辑实现方法，返回结果封装为统一的响应数据模型ResponseEnvelope；需要说明的是，回结果是业务方法的返回值，不同的业务请求返回的结果不一样。相应数据模型的作用就是为了解决返回数据格式不统一，使返回结果格式统一方便在下一步中coreAction解析所有业务实现的返回结果

控制器coreAction解析返回数据模型ResponseEnvelope，更新视图层数据。

通过本方案全局使用一个核心控制器coreAction，一次开发全局使用，对开发人员只需实现第6步的业务逻辑，不需要再创建过多的控制器，减少开发工作量便于代码维护，对于用户请求使用唯一的url路径coreAction，通过设置请求参数requestId便可以成功调用业务逻辑实现，方便易用，对业务接口的管理只需要维护xml文件变可以实现接口和业务实现的关系管理。

在某一实施例中，如图2所示，一种业务的实现系统，包括：提取模块1102、配置文件解析模块1103、业务解析模块1104、调用模块1105和执行模块1106；

提取模块1102用于获取业务请求，并提取业务编号；

配置文件解析模块1103用于解析配置文件和业务编号，在解析结果中获取与业务编号对应的业务类和实现方法；

业务解析模块1104用于解析出业务类的全类名和实现方法的方法名；

调用模块1105用于通过反射动态调用方法调用全类名和方法名，来获得实现方法的类实例；

执行模块1106用于执行类实例，根据执行结果响应预设业务。

本申请方案通过提取业务请求的业务编号，解析配置文件和业务编号，在解析结果中获取与业务编号对应的业务类和实现方法，解析出业务类的全类名和实现方法的方法名，通过反射动态调用方法调用全类名和方法名，来获得实现方法的类实例，执行类实例，根据执行结果响应预设业务，通过本方案的方法全局使用一个核心控制器coreAction，一次开发全局使用，对开发人员只需实现业务逻辑，不需要再创建过多的控制器，降低开发人员的工作量、降低代码冗余，便于代码维护。

优选地，在上述任意实施例中，还包括：配置模块，

用于获取每个业务类对应的请求路径，以及每个实现方法对应的业务逻辑；

根据每个业务类和每个实现方法的映射关系，获取每个请求路径和每个业务逻辑的映射关系，根据每个请求路径和每个业务逻辑的映射关系构建所述配置文件。

本方案通过构建配置文件，对业务接口的管理只需要维护xml文件，就可以实现接口和业务实现的关系管理。

优选地，在上述任意实施例中，还包括：业务编码构建模块，用于根据每个业务类型分别建立业务类和实现方法的映射关系，并设置每个业务类型的业务编号。本方案通过根据业务编码分别建立业务类和实现方法的映射关系，对于用户请求使用唯一的url路径coreAction，通过设置请求参数requestId便可以成功调用业务逻辑实现，方便易用。

优选地，在上述任意实施例中，还包括：更新模块，用于将执行结果封装为响应数据模型；

通过控制器解析响应数据模型，根据解析结果更新视图层数据。

本方案根据解析结果更新视图层数据，实现在数据变化时更新视图，使得视图与模型分离。

优选地，在上述任意实施例中，还包括：请求模块1101，用于根据预设业务发起业务请求，并发送相应的业务编号。

可以理解，在一些实施例中，可以包含如上述各实施例中的部分或全部可选实施方式。

需要说明的是，上述各实施例是与在先方法实施例对应的产品实施例，对于产品实施例中各可选实施方式的说明可以参考上述各方法实施例中的对应说明，在此不再赘述。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种业务的实现方法，其特征在于，包括:

获取业务请求，并提取与所述业务请求对应的业务编号；

解析配置文件获取与所述业务编号对应的业务类和实现方法；

解析出所述业务类的全类名和所述实现方法的方法名；

通过反射动态调用方法调用所述全类名和所述方法名，来获得所述实现方法的类实例；

执行所述类实例，根据执行结果响应所述预设业务。

2.根据权利要求1所述的一种业务的实现方法，其特征在于，所述根据所述业务编号在解析结果中获取与所述业务编号对应的业务类和实现方法之前还包括：

根据每个业务类型分别建立业务类和实现方法的映射关系，并设置每个业务类型的业务编号。

3.根据权利要求2所述的一种业务的实现方法，其特征在于，所述解析配置文件之前还包括：

获取每个业务类对应的请求路径，以及每个实现方法对应的业务逻辑；

根据每个业务类和每个实现方法的映射关系，获取每个请求路径和每个业务逻辑的映射关系，根据每个请求路径和每个业务逻辑的映射关系构建所述配置文件。

4.根据权利要求1-3任一项所述的一种业务的实现方法，其特征在于，还包括：

将所述执行结果封装为响应数据模型；

通过控制器解析所述响应数据模型，根据解析结果更新视图层数据。

5.根据权利要求2所述的一种业务的实现方法，其特征在于，还包括：

根据预设业务发起业务请求，并发送相应的业务编号。

6.一种业务的实现系统，其特征在于，包括：提取模块、配置文件解析模块、业务解析模块、调用模块和执行模块；

所述提取模块用于获取业务请求，并提取与所述业务请求对应的业务编号；

所述配置文件解析模块用于解析配置文件获取与所述业务编号对应的业务类和实现方法；

所述业务解析模块用于解析出所述业务类的全类名和所述实现方法的方法名；

所述调用模块用于通过反射动态调用方法调用所述全类名和所述方法名，来获得所述实现方法的类实例；

所述执行模块用于执行所述类实例，根据执行结果响应所述预设业务。

7.根据权利要求6所述的一种业务的实现系统，其特征在于，还包括：业务编码构建模块，用于根据每个业务类型分别建立业务类和实现方法的映射关系，并设置每个业务类型的业务编号。

8.根据权利要求7所述的一种业务的实现系统，其特征在于，还包括：配置模块，用于获取每个业务类对应的请求路径，以及每个实现方法对应的业务逻辑；

根据每个业务类和每个实现方法的映射关系，获取每个请求路径和每个业务逻辑的映射关系，根据每个请求路径和每个业务逻辑的映射关系构建所述配置文件。

9.根据权利要求6-8任一项所述的一种业务的实现系统，其特征在于，还包括：更新模块，用于将所述执行结果封装为响应数据模型；

通过控制器解析所述响应数据模型，根据解析结果更新视图层数据。

10.根据权利要求7所述的一种业务的实现系统，其特征在于，还包括：请求模块，用于根据预设业务发起业务请求，并发送相应的业务编号。

Images