基于MVC分层的业务处理方法、装置和系统与流程

本发明涉及通信领域，特别涉及一种基于MVC分层的业务处理方法、装置和系统。

背景技术：

随着Internet技术的不断完善，当前信息化系统建设的趋势，是采用B/S(Browser/Server，浏览器/服务器模式)结构代替C/S(Client/Servers，客户端/服务器)结构。基于B/S结构的项目，相对传统的C/S结构，由于业务逻辑集中在服务器端，简化了客户端的负荷，但加重了服务器端的负荷，使得基于B/S结构的项目在系统架构方面需要有更清晰的层次结构，从而涌现出大量的MCV框架。

MVC是一种目前广泛流行的软件设计模式。近年来，随着J2EE的成熟，MVC得到了广泛使用，并成为J2EE平台上推荐的一种设计模式。如图1所示，MVC(Model/View/Controller，模型/视图/控制器)模式正是将系统划分为模型层、视图层、控制层，因此，MVC模式适应了日益复杂的Web应用系统的设计需求。现有的MVC框架业务流程如图2所示。

但是，在采用MVC模式构建的Web应用系统的体系结构中，如何解决在Web应用系统开发过程中由于系统结构的复杂程度较高而带来的业务代码间的耦合度较高、代码的易维护性较差，提高应用框架的可重用性、组件的可重用性等问题，是目前要急需解决的。

技术实现要素：

本发明实施例提供一种基于MVC分层的业务处理方法、装置和系统，通过在MVC分层中进一步增加业务分层，从而使得传统MVC分层在架构上更加清晰，增加了系统的灵活性，有效实现业务代码分离，以解除对象之间的耦合。

根据本发明的一个方面，提供一种基于MVC分层的业务处理方法，包括：

在接收到业务调用方发送的调用请求后，调用相应的函数进行处理，以得到业务处理结果；

将所述业务处理结果返回给所述业务调用方。

在一个实施例中，所述业务调用方为控制器模块或数据访问对象DAO模块。

在一个实施例中，调用相应的函数进行处理以得到业务处理结果还包括：

调用DAO模块进行相应的数据业务处理。

在一个实施例中，所述调用请求还包括指定数据类型信息，以便返回的所述业务处理结果与所述指定数据类型信息相匹配。

根据本发明的另一方面，提供一种基于MVC分层的业务处理模块，包括接收单元、业务处理单元和发送单元，其中：

接收单元，用于接收业务调用方发送的调用请求；

业务处理单元，用于在接收单元接收到业务调用方发送的调用请求后，调用相应的函数进行处理，以得到业务处理结果；

发送单元，用于将所述业务处理结果返回给所述业务调用方。

在一个实施例中，所述业务调用方为控制器模块或数据访问对象DAO模块。

在一个实施例中，业务处理模块还包括业务调用单元，其中：

业务调用单元，用于调用DAO模块进行相应的数据业务处理。

在一个实施例中，所述调用请求还包括指定数据类型信息，以便返回的所述业务处理结果与所述指定数据类型信息相匹配。

根据本发明的另一方面，提供一种基于MVC分层的业务处理系统，包括上述任一实施例涉及的业务处理模块，以及

业务调用方，用于向所述业务处理模块发送调用请求，还用于接收所述业务处理模块返回的业务处理结果。

在一个实施例中，所述业务调用方为控制器模块或数据访问对象DAO模块。

在一个实施例中，控制器模块还用于在接收到所述业务处理模块返回的业务处理结果后，将所述业务处理结果提供给视图层模块以呈现给用户。

通过以下参照附图对本发明的示例性实施例的详细描述，本发明的其它特征及其优点将会变得清楚。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为MVC框架体系结构示意图。

图2为现有技术中MVC框架业务流程示意图。

图3为本发明基于MVC分层的业务处理方法一个实施例的示意图。

图4为本发明基于MVC分层的业务处理模块一个实施例的示意图。

图5为本发明基于MVC分层的业务处理模块另一实施例的示意图。

图6为本发明基于MVC分层的业务处理系统一个实施例的示意图。

图7为本发明MVC框架业务流程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

图3为本发明基于MVC分层的业务处理方法一个实施例的示意图。可选地，本实施例的方法步骤可由业务处理模块执行，其中：

步骤301，在接收到业务调用方发送的调用请求后，调用相应的函数进行处理，以得到业务处理结果。

步骤302，将所述业务处理结果返回给业务调用方。

可选地，业务调用方可为控制器模块或数据访问对象DAO模块。

例如，在控制器模块中充斥着大量的业务代码，其中会多次调用函数F，为了能够实现分离业务代码，解除对象间的耦合，将函数F封装到业务处理模块中，从而当控制器模块调用函数F时，通过与业务处理模块的交互，从而获得函数F的运算结果，由此可使业务逻辑更加清晰。

相应地，在数据访问对象DAO模块中的业务代码也需要调用函数F时，也通过与业务处理模块的交互，从而获得函数F的运算结果。

基于本发明上述实施例提供的基于MVC分层的业务处理方法，通过在MVC分层中进一步增加业务分层，从而使得传统MVC分层在架构上更加清晰，增加了系统的灵活性，有效实现业务代码分离，以解除对象之间的耦合。

可选地，在上述实施例中，调用相应的函数进行处理以得到业务处理结果的步骤还可包括：

调用DAO模块进行相应的数据业务处理。

也就是说，若业务处理模块根据接收到的业务请求，还需要调用DAO模块进行相应的业务处理，则调用DAO模块进行相应的数据业务处理、持久化操作、实现数据的增删改查以及封装数据库映射成相应的模型model对象等。

可选定，在上述实施例中，调用请求还包括指定数据类型信息，以便返回的所述业务处理结果与指定数据类型信息相匹配。

例如，控制器模块需要业务处理模块返回的是字符串类型的结果，则业务处理模块会直接为控制器模块提供字符串类型的业务处理结果，从而无需控制器模块对接收到的结果进行转换。通过这种泛型接口设计，可有效提高系统的处理效率。

图4为本发明基于MVC分层的业务处理模块一个实施例的示意图。如图4所示，该业务处理模块可包括接收单元401、业务处理单元402和发送单元403。其中：

接收单元401用于接收业务调用方发送的调用请求。

业务处理单元402用于在接收单元401接收到业务调用方发送的调用请求后，调用相应的函数进行处理，以得到业务处理结果。

发送单元403用于将业务处理结果返回给业务调用方。

可选地，上述业务调用方可为控制器模块或数据访问对象DAO模块。

此外，上述调用请求还包括指定数据类型信息，以便返回的业务处理结果与指定数据类型信息相匹配。

基于本发明上述实施例提供的基于MVC分层的业务处理装置，通过在MVC分层中进一步增加业务分层，从而使得传统MVC分层在架构上更加清晰，增加了系统的灵活性，有效实现业务代码分离，以解除对象之间的耦合。

图5为本发明基于MVC分层的业务处理模块另一实施例的示意图。与图4所示实施例相比，除接收单元501、业务处理单元502和发送单元503之外，还进一步包括业务调用单元504，其中：

业务调用单元504用于调用DAO模块进行相应的数据业务处理。

图6为本发明基于MVC分层的业务处理系统一个实施例的示意图。如图6所示，该系统可包括业务调用方601和业务处理模块602，其中业务处理模块602可为图4或图5中任一实施例涉及的业务处理模块。

业务调用方601用于向业务处理模块602发送调用请求，还用于接收业务处理模块602返回的业务处理结果。

可选地，业务调用方601可为控制器模块或数据访问对象DAO模块。

此外，在业务调用方601为控制器模块的情况下，控制器模块还用于在接收到业务处理模块返回的业务处理结果后，将业务处理结果提供给视图层模块以呈现给用户。

图7为本发明MVC框架业务流程示意图。与图2所示的现有技术相比，在控制器模块和DAO模块之间设置业务处理模块，从而有效实现业务代码分离，以解除对象之间的耦合。下面对其中的一种具体实现进行说明。

模型(Model)：模型作为应用程序的主体部分，它既能表示业务数据又表示业务逻辑。一个模型能为多个视图提供数据，同时由于同一个模型可以被多个视图重用，所以提高了应用的可重复性。

视图(View)：视图即用户看到并与之交互的界面。它既能向用户显示一个或多个模型数据，同时也能接收用户的输入数据，但它并不进行任何实际的业务处理，不会改变模型状态。视图可以向模型查询业务状态，视图还能接受模型发出的数据更新事件，从而对用户界面进行同步更新。

控制器(Controller)：一般来说控制器接受用户的输入并调用模型和视图去完成用户的需求。一方面它解释来自于视图的输入，将其解释成为系统能够理解的对象；另一方面，它处理来自于模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。

业务处理模块(Service)：业务处理模块(即业务层)的加入使得分层架构上更加清晰，增加了系统的灵活性。业务层的应用有三种策略：一：偏向于Controller层；二：偏向于Model层；三：前两者的结合。本发明的一个实施例采用第三种策略，但也可适用其它策略。通过编写泛型接口BaseService<T,K>(T与Model层对象对应，K为Model层对应数据库主键在Model中的类型)，定义了Model层的基本实现，应且在Service中需要包含大部门的业务逻辑。

例如，在一个具体实现中，前端控制器FrontController进行匹配请求的拦截。创建控制器父类BaseController，声明实例变量HttpServletRequest、HttpServletResponse、HttpSession，通过J2EE注解@Resource自动装配Bean对象，获取request、respons及session对象，Controller层继承BaseController。

部分业务层不仅需要包含大部分业务逻辑，同时要提供基础性的数据服务，该service则需继承父接口BaseService<T,K>，以实现对Model层数据的基本封装处理，部分业务层仅需包含业务逻辑则不需要继承父接口BaseService<T,K>，而对基础性数据的服务可以通过调用其他继承了BaseService<T,K>的Service层。

控制层调用业务层service，对请求数据进行处理或(及)调用DAO层对数据进行封装再处理，进一步将数据传递给视图层View，经渲染呈现给前端用户展示。

service层基本接口，T与Model层对象对应，K为Model层对应数据库主键在Model中的类型：

DAO层进行数据业务处理、持久化操作，实现数据的增删改查以及封装数据库映射成相应的model对象。

model层对应数据库，DAO层封装数据库数据到对应model对象，简化了service层对数据的处理，Controller获取处理后的model层数据，返回给视图层，视图层渲染相应数据呈现到前端用户，以便用户的实时交互。

通过实施本发明，可以得到以下有益效果：

1)分离业务代码，解除对象之间的耦合。

2)封装了通用BaseService<T,K>泛型接口，明确了Service智能。

3)降低了系统耦合性，增加了系统可扩展性。

4)便于系统维护。

基于本发明所具有的上述优势，可将其应用到基于MVC分层的Web项目开发、基于泛型接口的应用开发等场景中。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。