MVC设计模式基于J2EE的WEB应用开发框架——WebFramework

MVC设计模式基于J2EE的WEB应用开发框架——WebFramework

关键词MVC设计模式; J2EE; 框架; 支柱

介绍

随着开源软件的兴起,各种框架相继出现,比如Apache的开源框架Struts就是典型代表。 在实际软件开发中使用这些框架,大大降低了J2EE开发的复杂度和难度,降低了开发成本。 但这些框架也存在缺点,如掌握难度大、配置复杂等。本研究的目的是设计一个简单易用的WEB开发框架——WebFramework。 WebFramework结构清晰,易于理解,增加了系统的可扩展性和可维护性,降低了开发成本。

MVC设计模式

大多数基于J2EE的WEB应用系统都使用MVC模式来实现其体系结构。 MVC(模型-视图-控制器)是 20 世纪 80 年代为编程语言 Smalltalk-80 发明的软件设计模式。 MVC 模式将交互式应用程序分为三个部分:模型、视图和控制器[1]。 模型是指从现实世界中挖掘出来的对象模型,是应用逻辑的反映。 模型封装了数据和对数据的操作,是实际执行数据处理计算的地方。 视图是应用程序和用户之间的界面。 它负责向用户呈现应用程序并显示模型的状态。 控制器负责视图和模型之间的交互,并控制对用户输入的响应方法和过程。 它主要负责两方面的动作:将用户请求分发到对应的模型; 并及时响应模型到视图的变化。 MVC 将这些对象分开以提高灵活性和可重用性。 MVC模式的结构如图1所示:

图1 MVC设计模式结构

Struts框架

Struts 是 Apache 基金会 Jakarta 项目团队的一个开源项目。 它使用Servlet2.2和JSP1.1标签作为实现的一部分。 它由一组协作类、servlet 和 JSP 标记组成,形成一个可重用的系统。 设计。 它可以很好地帮助Java开发人员使用J2EE开发WEB应用程序。 充分发挥了设计模式中“显示逻辑与业务逻辑分离”的能力。 因此,越来越多的大型WEB应用项目正在使用Struts框架进行开发,或者借鉴Struts的架构设计来开发基于MVC模式的应用系统。

Struts的工作原理如图2所示:

图 2 Struts 的工作原理

Struts的优点主要体现在两个方面:表单验证和页面导航。 表单验证解决了请求数据验证的问题,增强了系统的健壮性。 页面导航使得系统的业务流程清晰基于mvc设计模式的网页游戏开发技术研究,系统各部分之间的联系可以通过配置文件体现出来,从而在一定程度上简化了系统的日后维护。

但Struts也有一些缺点:

1)陡峭的学习曲线。 Taglib是Struts的标签库。 如果能够灵活运用,可以大大提高开发效率。 但对于初学者来说,需要一个不断学习的过程,这就增加了系统开发的成本。

2)增加了系统的复杂性。 业务层和表现层耦合度太高,导致开发人员无法专注于表现层的设计和实现。

3)没有前端验证表单数据的解决方案,不利于在大型系统中使用。

4)配置文件过于复杂、繁琐。 随着系统规模的增大,struts-config.xml变得越来越大,维护也越来越困难。

WebFramework框架

针对Struts框架的上述缺点,本文提出WebFramework框架。 与Struts框架相比,WebFramework更加简单,更容易实现。 通过简化表示层的设计,降低开发难度,节省开发成本; 它采用VO(Value Object)作为数据的传输方式,降低了系统复杂度; 采用简单的浏览器端表单字段数据验证,提高了系统的运行效率; 简化的配置文件,方便系统维护。

设计目标

遵循J2EE规范,基于多层分布式应用软件开发框架,分布式分层架构可以提高软件系统性能的可扩展性,从长远角度保护客户当前的软件投资; 实现软件系统在出现异常情况下任何情况下都能正常提供服务,提高软件系统的稳定性; 各个架构层次的逻辑分离有利于软件开发过程中团队成员的协同工作,提高生产效率。

2、框架结构

在设计策略上,软件系统从架构上分为数据层、业务逻辑层和表示层,主要关注业务表示层和业务逻辑层。 常见的三层架构的表示层又细分为视图格式层和表示控制逻辑层。 表示层涉及基于“瘦客户端”技术的用户视图格式的服务器端表示以及相应的交互控制逻辑。 视图格式层只保留构建客户端用户视图所必需的显示格式和事件触发; 而表示控制逻辑层,顾名思义,实现了人机交互所需的控制逻辑和部分业务会话逻辑。 与贯穿系统各逻辑层的业务实体一起,形成了以MVC模型为核心的表现层架构,有效分离了显示格式、显示控制逻辑和模型数据,大大增强了系统的可靠性建筑学。 应用程序子系统的可扩展性和可插拔性。

业务层又细分为业务会话层和业务持久层。 业务层重点关注业务流程中处理逻辑的组件封装,与数据层平台和外部系统无关。 业务会话层关注业务活动,以事务方式封装一个业务的所有活动,保证业务流程处理的一致性和高效性; 而业务持久层为业务会话层提供支持,提供业务数据持久化操作,建立中间层,将业务和数据库分离,形成松耦合的架构。

MVC 设计模式就是在这种分层模型中实现的。 其中,Servlet组件对应MVC中的Controller部分,JSP和Browser对应View部分,会话外观、逻辑bean和值对象对应Model部分。 其结构如图3所示:

2.1. 数据层

(1) 图层定义

数据层管理数据并向业务逻辑层提供标准化的开放访问接口。

数据层目前主要提供两种形式的服务方法:数据库方法和文件方法。 数据库主要为业务运营数据等具有明显结构化特征的数据提供存储和访问服务; 文件主要提供包括扫描文档图像、传真、照片、计算机生成的报告、文字处理文档、电子表格、演示文稿、语音和视频片段等非结构化数据的存储和访问服务。

主要功能:数据创建、数据存储、数据查询、数据更新、数据删除、数据安全、事务支持、数据备份/恢复。

(2) 与其他层的接口

1)数据库模式的数据层向业务逻辑层提供数据库访问服务接口,业务逻辑层通过JDBC协议访问数据库服务。

2)基于文件的数据层向业务逻辑层提供文件级访问服务接口,业务逻辑层通过操作系统本身提供的文件访问API来访问文件数据。

图3MyFramework框架结构图

2.2 业务逻辑层

(1) 图层定义

业务逻辑层接受表示层输入的用户请求游戏素材下载 免费,将其转换为业务逻辑流程能够理解的方式,按照具体的业务逻辑有序地将数据请求发送到数据层,并对返回的数据进行解释和组合由数据层转化为用户所需的信息返回到表示层,它是整个应用软件系统中业务逻辑实现和处理的核心。 业务逻辑层运行在基于J2EE应用服务器的EJB和WEB容器中。

(2)组件定义

业务逻辑层包括三个逻辑组件:Session Façade、Logic Bean 和 Data Access Bean。

1) 会议外观

为表现层提供统一的业务逻辑调用接口; 它是数据访问事务的边界。 所有数据访问事务均由会话外观管理,即会话外观负责数据访问事务的启动和关闭。

业务逻辑是如何完成的:业务逻辑是通过调用逻辑bean来实现的。

2)逻辑Bean

提供业务逻辑的具体实现; 具有复用性:可以直接被会话外观调用,实现会话外观所需的业务逻辑; 可以被其他逻辑bean调用,此时这个逻辑bean充当更复杂的业务逻辑组件的组件。

如何完成业务逻辑:相对复杂的业务逻辑可以通过调用其他逻辑bean来实现; 直接调用数据访问bean就可以完成比较简单的业务逻辑。

3)数据访问Bean

提供数据层的访问接口; 它不负责管理事务,只是被动地使用调用者传入的事务环境; 与数据库表的映射方法通常采用单个数据表对应单个数据访问bean的映射方法基于mvc设计模式的网页游戏开发技术研究,由单个数据访问bean包含单个数据表对应的所有相关数据访问操作。

4)值对象

包含业务逻辑实体的属性,不包括业务逻辑实体的操作; 它是表示层和业务逻辑层之间数据交换的主要单元。 它与会话外观一起形成一个完整的业务逻辑实体,提供业务逻辑层到表示层的统一。 界面; 与数据库表的映射方法通常采用单个数据表对应单个值对象的映射方法。 它可以与不同类型的值对象聚合形成新的值对象。

(3) 与其他层的接口

1)会话门面为表示层提供业务逻辑调用接口游戏图片,表示层通过Java本地调用访问业务逻辑层。

2)数据访问bean通过JDBC访问数据库服务。

3)数据访问bean通过操作系统提供的系统服务访问文件数据。

2.3 表示层

(1) 图层定义

表现层接受用户提交的输入请求,通过访问业务逻辑层获取并输出可视化响应给用户。

(2)组件定义

使用MVC设计模式,Servlet提供对页面请求和请求响应的总体控制,JSP和浏览器提供请求结果和响应的可视化显示。

1)Servlet

接收用户通过浏览器提交的所有业务请求,合成相应的值对象,访问业务逻辑层完成业务逻辑实体的业务处理; 以值对象的形式通知业务逻辑实体的变化并将其转发到相应的JSP。

2) 联合应用程序

根据Servlet通知的值对象,合成请求响应结果最终输出的格式化文本(HTML); 合成的格式化文本以网络协议的形式发送到提交业务请求的用户浏览器。

3)浏览器

提供输入接口供用户输入业务请求数据,数据验证通过后提交业务请求; 接收业务请求响应的HTML文本,并将业务请求响应结果以可视化的方式呈现给用户。

4)网络服务

它是业务逻辑层向外部系统提供服务的边界和接口,完成与外部系统的集成和交互。

(3) 与其他层的接口

1)Servlet通过Java本地调用来访问业务逻辑层。

文章来源:https://blog.csdn.net/xinguojava/article/details/6330475