一种弹性可扩展的多数据源mvc模型架构的制作方法
【专利摘要】本发明涉及软件技术开发领域，具体涉及一种弹性可扩展的多数据源mvc模型架构。本发明针对每个数据源都有其相应的模型层，也就是业务逻辑处理层，而不同数据源又通过统一的控制器层来统一控制业务层跟表现层的交互；表现层可根据需要灵活动态选择多数据源业务；针对不同数据源都有相应子mvc模式与其对应；表现层和控制层不是独立设计的，控制层是共用的，表现层也大都是混用的，也就是同一个视图界面可以同时调用不同数据源业务。本发明解决了现有应用程序动态扩展多数据源其他相关业务不易的问题；可以用于Web应用程序的开发。
【专利说明】一种弹性可扩展的多数据源mvc模型架构
【技术领域】
[0001]本发明涉及软件技术开发领域，具体涉及一种弹性可扩展的多数据源mvc模型架构。
【背景技术】
[0002]面向对象技术的出现与广泛使用，使得软件的可复用性在一定层度上得到了解决；但由于软件规模和复杂程度的增加以及很多其他方面的原因，人们对软件复用同时也要求越来越高。结构清晰、便于复用、易于维护和可扩展，是目前软件设计所追求的目标。因而mvc (model-view-controller，模型-视图-控制器)做为一种主流的设计模式应运而生。它将应用程序分成三个核心部件:模型、视图、控制器。集成SSH框架的系统从职责上分为四层:表示层、业务逻辑层、数据持久层和域模块层，以帮助开发人员在短期内搭建结构清晰、可复用性好、维护方便的Web应用程序。其中使用Struts作为系统的整体基础架构，负责MVC的分离，在Struts框架的模型部分，控制业务跳转，利用Hibernate框架对持久层提供支持，Spring做管理，管理struts和hibernate。但是，随着时间推移，MVC模式也暴露出大量缺点，因为MVC模式本质上是一个结构型模式。结构模式相比行为模式而言，实际就是静止的，相对固定的，而随着B/S和互联网应用不断普及，相对静止的MVC模式已经不适合高度交互注重行为的应用了。一般的ssh框架都是基于单一数据源基础上设计的三层架构，过于模式化，对web容器有很强的依赖，不容易动态扩展多数据源其他相关业务。
【发明内容】
[0003]本发明解决的技术问题在于提供一种弹性可扩展的多数据源mvc模型架构；基于多数据源情况下，可灵活扩展相关业务逻辑处理的架构。
[0004]本发明解决上述技术问题的技术方案是:
[0005]针对每个数据源都有其相应的模型层，也就是业务逻辑处理层，而不同数据源又通过统一的控制器层来统一控制业务层跟表现层的交互；表现层可根据需要灵活动态选择多数据源业务；针对不同数据源都有相应子mvc模式与其对应；表现层和控制层不是独立设计的，控制层是共用的，表现层也大都是混用的，也就是同一个视图界面可以同时调用不同数据源业务。
[0006]对于每个数据源对应的模型层都通过统一的baseDao层及baseService层实现，但并非每个数据源都要写对应的代码层，可直接通过上下文配置不同javabean名称即可；上层通过配置的名字直接进行baseService层基础操作接口调用；根据需要及hibernate的特征，有时需要根据数据源库表配置Po持久化对象及映射文件等。
[0007]所述的架构基于ssh(struts+spring+hibernate)技术之上。
[0008]多数据源可以根据实际需要通过扩展添加相关上下文配置信息的方式接入，此种方式下扩展接入的数据源会在应用部署到项目时就进行持久连接；也可以根据系统需要，临时通过代码组建，这样事务管理、java bean等都统一通过spring及hibernate进行管理。
[0009]通过本发明的架构，用户只需扩展增加相关配置文件信息及按需添加数据库库表相关的映射代码，就可以扩展并发执行多数据源业务逻辑事务处理。同时，用户也可以根据数据源连接信息动态构建相关数据源下的基础业务逻辑处理层，程序直接调用基础接口方法便可以简便的处理上层针对此数据源的业务处理。
【专利附图】
【附图说明】
[0010]下面结合附图对本发明进一步说明:
[0011]图1为系统实现本方法的整体架构图
[0012]图2为本发明代码实现结构图。
【具体实施方式】
[0013]为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0014]本发明框架针对每一个数据源设计子mvc模型，当然它们又是一体的，都是构建在相同开源框架代码之上的。典型的J2EE三层结构，分为表现层、中间层(业务逻辑层)和数据服务层。三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库交互。表现层是传统的JSP技术，自1999年问世以来，经过多年的发展，其广泛的应用和稳定的表现，为其作为表现层技术打下了坚实的基础。中间层采用的是流行的Spring+Hibernate，为了将控制层与业务逻辑层分离，又细分为以下几种。Web层，就是MVC模式里面的“C” (controller)，负责控制业务逻辑层与表现层的交互，调用业务逻辑层，并将业务数据返回给表现层作组织表现，该系统的MVC框架采用Struts。Service层(就是业务逻辑层)，负责实现业务逻辑。业务逻辑层以DAO层为基础，通过对DAO组件的正面模式包装，完成系统所要求的业务逻辑。DAO层，负责与持久化对象交互。该层封装了数据的增、删、查、改的操作。PO，持久化对象。通过实体关系映射工具将关系型数据库的数据映射成对象，很方便地实现以面向对象方式操作数据库，该系统采用Hibernate作为ORM框架。Spring的作用贯穿了整个中间层，将上eb层、Service层、DAO层及PO无缝整合，其数据服务层用来存放数据。可扩展多数据源mvc模型架构针对每个数据源都是依照以上原理设计，但中间层及表现成可以根据需要灵活设计，并非固定模式化。通过统一的control层统一控制业务层跟表现层的交互。所有的javabean统一 spring的1c模式管控。
[0015]图1为本发明此动态可扩展mvc整体架构图，针对每个数据源都有其相应的model层，也就是业务逻辑处理层，而不同数据源又通过统一的control层来统一控制业务层跟表现层的交互。表现层可根据需要灵活动态选择多数据源业务。针对不同数据源都有相应子mvc模式与其对应。只是表现层跟控制层不是独立设计的，控制层是共用的，表现层也大都是混用的，也就是同一个视图界面可以同时调用不同数据源业务。
[0016]图2为本框架代码实现结构图，对于每个数据源对应的model成都通过统一的baseDao层及baseService层实现，但并非每个数据源都要写对应的代码层，程序员直接通过上下文配置不同javabean名称就可以了，上层通过配置的名字直接进行baseService层基础操作接口调用。当然根据需要及hibernate的特征，程序员有时需要根据数据源库表配置Po持久化对象及映射文件等。
【权利要求】
1.一种弹性可扩展的多数据源mvc模型架构，其特征在于:针对每个数据源都有其相应的模型层，也就是业务逻辑处理层，而不同数据源又通过统一的控制器层来统一控制业务层跟表现层的交互；表现层可根据需要灵活动态选择多数据源业务；针对不同数据源都有相应子mvc模式与其对应；表现层和控制层不是独立设计的，控制层是共用的，表现层也大都是混用的，也就是同一个视图界面可以同时调用不同数据源业务。
2.根据权利I所述的弹性可扩展的多数据源mvc模型架构，其特征在于:对于每个数据源对应的模型层都通过统一的baseDao层及baseService层实现，但并非每个数据源都要写对应的代码层，可直接通过上下文配置不同javabean名称即可；上层通过配置的名字直接进行baseService层基础操作接口调用；根据需要及hibernate的特征，有时需要根据数据源库表配置Po持久化对象及映射文件等。
3.根据权利I所述的弹性可扩展的多数据源mvc模型架构，其特征在于:所述的架构基于 ssh (struts+spring+hibernate)技术之上。
4.根据权利2所述的弹性可扩展的多数据源mvc模型架构，其特征在于:所述的架构基于 ssh (struts+spring+hibernate)技术之上。
5.根据权利I至4任一项所述的弹性可扩展的多数据源mvc模型架构，其特征在于:多数据源可以根据实际需要通过扩展添加相关上下文配置信息的方式接入，此种方式下扩展接入的数据源会在应用部署到项目时就进行持久连接；也可以根据系统需要，临时通过代码组建，这样事务管理、java bean等都统一通过spring及hibernate进行管理。
【文档编号】G06F9/44GK104484182SQ201410831700
【公开日】2015年4月1日 申请日期:2014年12月25日 优先权日:2014年12月25日
【发明者】郭树盛, 唐素芳, 徐志伟 申请人:广东电子工业研究院有限公司