（检测技术与自动化装置专业论文）基于j2ee的web整体框架的设计与应用.pdf

西南交通大学硕士研究生学位论文第 页 摘要 随着网络技术的发展，大量企业采用基于i n t e r n e t 的应用来构筑企业级 信息系统。j 2 e e 作为现今最流行的分布式计算平台，己成为基于w e b 的企业应 用系统的核心。 但j 2 e e 本身只是广泛意义上的一种企业解决方案。多层的j 2 e e 体系结构 在提高软件重用性和分解问题复杂性的同时，也使得代码庞大，层与层之间的 控制关系复杂。于是人们将同类问题的解决方法进行抽象，抽取成一个框架。 可重用、易扩展，并且经过良好测试的框架，越来越为人们所青睐。在开发j 2 e e 应用时，可以选择不同的框架来解决不同的问题。 本文探讨了如何组合各种框架来搭建通用的w e b 整体框架。w 曲整体框架 相当于j 2 e e 平台和应用软件的中间层，是应用的骨架，解决了应用中所有非 业务逻辑部分的实现，使开发者仅关注业务逻辑的开发。 本文对j 2 e e 的四层体系结构及改进的五层体系结构进行了介绍和对比， 对数据持久层引入的原因和意义进行了分析，对j 2 e e 组件、容器进行了介绍。 本文介绍了m v c 设计模式的原理，分析了m v c 设计模式的优缺点和适 用范围，并将m v c 设计模式引入到w e b 整体框架的设计中。 根据j 2 e e 五层体系结构划分的层次，本文分别对w 曲层、业务逻辑层、 数据持久层的实现策略进行了介绍：采用s 扛1 l t s 、j a t o 、c o c o o n 框架来实现 w 曲层，采用j a v a b e a n 或会话e j b 来实现业务逻辑层，采用j d b ca p i 封装、 o r m 工具、实体e j b 来实现数据持久层。在分别对每个层次的可选框架和技 术进行介绍和比较的基础上，进而提出了整体框架的几种设计方法，并对这几 种整体框架的适用范围进行了说明。最后，通过一个实际的项目来说明基于 s t r u t s + j a v a b e a n + h i b e m a t e 框架的应用的开发过程，并以此证明w 曲整体开发 框架的可行性。 关键词：j 2 e e ；框架；整体框架；w 曲：s 订1 l t s ；h i b e m a t e 西南交通大学硕士研究生学位论文第1 li 页 t 0 0 1 s 、e n t i t ye j bh a v eb e e nu s e di nd a t ap e r s i s t e n tt i e lb a s e do ni m r o c i u c t i o n sa n d c o m p a r i s o n so fa v a i l a b l e 丘锄e w o r k sa n dt e c h n o l o g i e sa te v e r y 廿e r ，m a l l yd e s i g i l m e t l l o d so fw 曲o v e 晤i lm m l e w o r kh a v eb e e np u tf o n v a r d ，a 1 1 dt 1 1 e i rs c o p e so f 印p l i c a t i o nh a v ea j s ob e c ng j v e n 。i nt h ee n d ，ap r a c t i c a lp r o j e c th a sb e e nu s e dt o d e m o n s t a t et 1 1 ed e v e l o p m e mp r o c e s so fs o f t w a r eb a s e do nw 曲o v e r a l l 丘啪e w o r k ， a n di t sf c a s i b i l i t yh a sa l s eb e e np r o v e d k e yw o r d s ：j 2 e 巳，f r a m e w o r k ，o v e r a i lf r a m e w o r k ，w e b ，s t r u t s ，h i b e m a t e 西南交通大学硕士研究生学位论文第1 页 第1 章绪论 1 1 课题研究背景及意义 随着网络技术和i n t e r n e t 的迅速发展，越来越多的企业应用系统通过 w e b 的方式来发布，基于浏览器服务器( b s ) 的应用成为开发者的首选。 目前的w e b 应用，尤其是企业级应用呈现出以下的特点：系统结构复杂、 功能繁多、事务密集、信息量大、用户数多、涉及较多的外部资源、对安全性 的要求较高等。 因此，原有的w e b 开发方式不再适应企业级应用的开发，它暴露出代码可 重用程度低、维护困难、程序应变能力较弱、代码庞大难以理解、软件的生产 率较低等问题。同时，现存的i t 资产也无法得到有效保留。开发一个新的应用 往往需要从头开始，而无法直接利用一些已有的设计思想、系统架构以及代码， 造成大量的重复劳动。 许多的研究人员都试图根据以往的开发经验，并将现有的技术进行组合， 从而设计一个合理的、能确保软件开发正常进行的整体开发框架。整体开发框 架相当于开发平台和应用软件之间的一个中间件，它搭建了软件的骨架。 所有的应用都可以在这个通用框架的基础上进行，软件的开发者只需实现 与业务逻辑相关的代码。而软件非业务逻辑的通用部分，即体系结构、系统各 部分间的协作和整合、公用服务功能等完全由开发框架来实现。在整体开发框 架为整个应用软件搭好了骨架，使得软件开发有章可循，开发周期大大缩短， 软件质量得到保证，现有的i t 资产得到有效的保留和重用。 可见，设计一个普遍适用且性能稳定可靠的整体开发框架有很大的意义。 1 2 课题研究的现状 要想完全自行构 x 西南交通大学硕士研究生学位论文第2 页 j 2 e e 是s u n 公司推出的多层分布式系统开发模型，提供了一个基于组件的 方法，来设计、开发、装配及部署企业应用程序。j 2 e e 体系结构是一个由客户 层、w e b 层、业务逻辑层、企业信息系统层( 数据层) 组成的四层结构。j 2 e e 技术的基础是j a v a2 平台的标准版，j 2 e e 不仅巩固了标准版中的许多优点， 例如”编写一次、随处运行”的特性、方便存取数据库的j d b ca p i 、c o r b a 技术以及能够在i n t e r n e t 应用中保护数据的安全模式等等，同时还提供了 对e j b 、j a v as e r v l e t sa p i 、j s p 以及x m l 技术的全面支持。 但是，j 2 e e 本身只是一种广泛意义上的企业解决方案。多层的j 2 e e 体系结 构在提高了软件重用性和分解了问题复杂性的同时。也使得代码庞大，层与层 之间的控制关系变得复杂。j 2 e e 框架原本希望用j s p s e r v l e t e j b 的三层架构 来分离网站的显示业务数据三层逻辑，但实践证明这种简单的分离并不十分 有效。j a v a 程序员往往会在j s p 页面中写下大量的j a v a 代码，使得业务逻辑、 流程控制、表示逻辑常常混夹在一起，变得难以阅读和维护，开发人员的分工 也无法明确。 因此，模型一视图一控制器( m v c ) 设计模式被引入到j 2 e b 平台。它强制 性地使应用程序的表示逻辑、流程控制和业务逻辑分开，即分成三个核心部件： 模型、视图、控制器。m v c 模式利用控制器来分离模型和视图，达到层间松散 耦合的效果。 一大批在j 2 e e 平台上实现m v c 设计模式的w e b 应用框架应运而生。应用框架 是解决某一特定问题的经验总结，是一个可复用的软件单元。其中比较流行的 框架有s t r u t s 、t u r b i n e 、c o c 0 0 n 等。这里所说的框架不同于整体开发框架， 整体开发框架是系统级的解决方案，而框架是局部问题的解决方法。 基于m v c 设计模式的框架很好地解决了“表示逻辑”与“业务逻辑”的 分离问题。这种分离在给开发者带来种种好处的同时，也启发了人们是否可以 把“业务逻辑”与“数据”也分离开来。业务逻辑代码和操作数据的代码混在 一起，使得系统的修改和维护非常困难。 因此，在业务逻辑层和数据层中插入数据持久层，从而把业务逻辑与数据 分离开的方案被提了出来。这样，j 2 e e 的四层体系结构就变成了五层体系结构， 即客户层、w e b 层、业务逻辑层、数据持久化层、企业信息系统层( 数据层) 。 西南交通大学硕士研究生学位论文第3 页 实现数据持久层的技术也纷纷出现，实体e j b 、j d o 、o r m 映射工具等都可以 从一定程度上解决问题。其中，一些充当o r m 映射工具的持久性框架被广泛的 应用。持久性框架位于数据源之上，对数据源进行封装，对业务逻辑层提供数 据访问的服务，将应用程序与其使用和操纵的数据源分离， 业务逻辑层是与应用的具体业务联系最为紧密的一块，也是编码量很大的 一块。业务逻辑层中的组件访问数据持久层，然后将结果数据提交给w 曲层， 起到承上启下的作用，是业务处理的核心。就实现技术来讲， j 2 e e 的相关组 件，如j a v a b e a i l 、e j b 中的s e s s i o i l b e a i l 等，都是可选的技术。由于这个层与 实际应用紧密相关，所以很难引入通用的框架来简化开发。 从上面的介绍可以看出，虽然j 2 e e 不能直接作为整体开发框架，但是可 以在j 2 e e 的多层体系结构之上，利用j 2 e e 的相关技术以及大量的现成框架来 搭建具有不同针对性的整体开发框架。 1 _ 3 课题研究的主要内容 论文旨在对j 2 e e 的各种开发技术、框架进行理论研究，分析它们各自的适 用范围和优缺点，从中选择合适的技术和框架，将其有机结合，组成适用于企 业级b s 系统的整体开发框架。 本文首先对j 2 e e 的相关理论进行了介绍，包括j 2 e e 的四层体系结构、组 件与容器。对四层的j 2 e e 架构进行了改进，添加数据持久层，形成五层的体系 结构。对j 2 e e 体系结构的优缺点也进行了分析。 提出把m v c 设计模式引入j 2 e e 架构中。详细介绍了m v c 模式的原理、工 作机制、优势与不足，以及m v c 模式的适用范围。介绍了对j 2 e e 平台上实现 m v c 的各种框架。 分别对w e b 层、业务逻辑层、数据持久层的实现策略进行了研究，详细介 绍了s t r u t s 框架、h i b e h l a t e 框架的体系结构、工作机制、适用范围等。提出了 w e b 整体开发框架的几种设计方法。 最后，结合一个实际项目( 项目计划管理系统) 来证明s 咖t s + j a v a b e a n + h i b e m a t e 整体开发框架的可行性，并对该项目的具体实现和关键技术做了介 绍。 西南交通大学硕士研究生学位论文第4 页 1 4 文章的组织结构 全文共分五章： 第一章：绪论，阐述课题研究的背景及意义、研究现状、研究的主要内容 和文章的组织结构。 第二章：j 2 e e 相关理论研究，介绍了j 2 e e 的四层体系结构和改进的五层 体系结构，j 2 e e 的组件与容器，并分析了j 2 e e 体系的优点和缺点。 第三章：w e b 整体开发框架的实现策略，介绍了m v c 设计模式和框架的概 念。对w e b 层、业务逻辑层、数据持久层可选用的技术、框架进行了介绍和比 较。最后对整体开发框架进行了设计。 第四章：项目计划管理系统的分析与建模，介绍了一个在s t m t s + j a v a b e a j l + h i b e m a t e 整体框架的基础上进行开发的实际应用，即项目计划管理系统。对 该系统的需求和功能实现进行了分析，并对系统进行了建模。 第五章：项目计划管理系统的详细设计，对项目计划管理系统的详细设计 进行介绍，并对实现过程中的关键技术做了阐述。 西南交通大学硕士研究生学位论文第5 页 第2 章j 2 e e 核心技术 j 2 e e 是一种利用j a v a2 平台来简化企业解决方案的开发、部署和管理相 关的复杂问题的体系结构“1 。j 2 e e 技术的基础就是j a v a2 平台的标准版。j 2 e e 不仅保留了标准版中的许多优点，同时还提供了对e j b 、j a v as e l e t s 、j s p 、 j d b c 以及l 技术的全面支持。j 2 e e 已成为用来开发企业应用和提供计算 解决方案的实事标准。 本章将介绍j 2 e f 的相关理论，如j 2 e e 的体系结构、组作、容器，并分析 j 2 e e 的优缺点。 2 1j 2 e e 的四层体系结构 j 2 e e 的四层体系结构图如图2 一l 所示。1 。 j 2 e e 应用l j 2 e e 应用2 应用客户端 动态h t m l 页面 【。，一。一【。+ 。，一 广= = 二_ j s p 贝曲 企业k 8 n 数据库 客户层 w 曲层 业务逻辑层i e l s 层 客户端机器 j 2 e e 服务器机器 数据库服务器机器 图2 一lj 2 e e 的四层体系结构 客户层：用来与用户交互，并把来自系统的信息显示给用户。j 2 e e 客户端 可i 三l 是w e b 浏览器也可以是桌面应用客户程序。 w e b 层：产生表示逻辑，并接受来自客户端的用户反馈。w 曲层通常在 w 曲服务器中实现。 业务逻辑层：处理应用的核心业务逻辑。它从w 曲层收到请求，根据请求 处理响应的业务逻辑。 企业信息系统层( e t s 层) ：包括企业基础建设系统例如企业资源计划 ( e r _ p ) 、大型机事务处理、数据库系统和其它的遗留信息系统。 ( e r p ) 、大型机事务处理、数据库系统和其它的遗留信息系统。 西南交通大学硕士研究生学位论文第6 页 从上面的图可以看出，j 2 e e 架构也可以被划分为三层。即从系统的物理层 次来考虑的，可以分为客户端机器、j 2 e e 服务器和数据库系统服务器。 2 2 改进的j 2 e e 五层体系结构 2 2 1 五层体系结构 j 2 e e 的四层体系结构使业务逻辑和表示逻辑分离开来，网页开发人员关注 表示逻辑的实现，后台开发人员关注业务逻辑的实现，大大提高了开发效率。 但是，这种体系结构仍然没有解决所有的问题。业务逻辑层不仅负责业务 逻辑，还直接访问数据库，实现对业务数据的保存、更新、删除、查询等操作。 因此业务逻辑代码和数据操作代码混杂在一起，当数据库平台或数据源发生改 变时，修改起来相当麻烦。 为了将数据访问细节和业务逻辑分开，可以把数据访问作为单独的数据持 久层分离出来，形成一个五层的体系结构。1 ，如图2 2 所示。 j 2 e e 应用ij 2 e e 应用2 面巫 臣堑匦 匠 互 夏 1 企业b e a n 或其它工具1 企业b e a f l 或其它工具 厂 厂 互 互 客户层 w e b 层 业务逻辑层f 数据持久层i e i s 层 客户端机器 j 2 e e 服务器机器 数据库服务器机器 图2 - 2 改进的五层体系结构图 所有与数据源相关的操作，如增加、删除、修改、查询以及事务管理、数 据库连接池管理、并发性控制、异常处理等都放在数据持久层里去。 本文所探讨的w 曲应用的整体开发框架就是基于这种五层体系结构的。 西南交通大学硕士研究生学位论文第7 页 2 2 2 增加数据持久层的优点 数据持久层的引入有如下优点。： 将数据持久逻辑和业务逻辑分离，业务逻辑层通过数据持久层与数据库 交互，而不是在业务代码中夹杂大量访问数据源的代码。各层功能简洁专一。 对业务逻辑层隐藏了数据库平台。将所有数据连接逻辑封装到数据持久 层中，业务逻辑的开发人员不需要知道数据库平台的类型以及连接数据库时所 需的任何安全信息( 用户i d 与口令) 。 抽象数据库中存储数据的物理细节和数据实体之间存在的关系。建立在 五层体系结构之上的应用程序不必直接对数据库发出s q l 查询，不必知道数据 的物理结构，而用数值对象访问数据库。 简化开发过程，隐藏打开数据库连接、发出数据读取与操纵命令和事务 管理的细节。 2 3j 2 e e 的组件 j 2 e e 应用是由组件组成的，组件是一段可重用的代码，是一个自我封装且 具有独立功能的软件单元。除了支持j 2 s e 中的j a v a b e a n 组件外，j 2 e e 规范还 定义了j 2 e e 专门的组件。 ( 1 ) 客户端组件 客户端组件驻留在客户层。一般情况下，客户端组件为最终客户提供一个 同j 2 e e 应用进行交互的g u i ”。客户端组件包括a p p l e t 和应用客户端。a p p l e t 是嵌在浏览器中的一种轻量级客户端，a p p l e t 会自动下载并在w e b 浏览器中执 行，显示给用户的只是执行的最终结果。应用客户端是一种重量级的客户端， 是独立的j a v a 程序，在浏览器之外运行。它可以在客户计算机上处理数据， 执行程序，因此可以为服务器分担负载。 ( 2 ) w 曲组件 w 曲组件是处理客户请求的软件实体，驻留在w 曲层。w 曲组件为客户 请求创建和返回一个合适的响应，为j 2 e e 应用提供服务器方表示能力。w 曲组 件包括s e r 、r l e t 和j s p 。s e r v l e t 是使用j a v as e r v l e ta p i 创建的类，它能动态处 理请求及响应。s e r v l e t 基于请求响应机制，它从客户端( 例如w 扑浏览器) 获得 请求，然后将响应结果返回客户端。j s p 是基于文本的文档，其中包含静态内 西南交通大学硕士研究生学位论文第8 页 容，以及为了产生动态内容的j a v a 代码片断，它是从s e r v l e t 技术发展而来的。 ( 3 ) 业务逻辑组件 业务逻辑是规则和代码的组合，这些规则和代码一起为企业解决特定领域 的问题。在j 2 e e 结构中，业务逻辑是由e j b ( e n t e r p r i s ej a v a b e 咖组件来实现的。 e j b 组件驻留在业务逻辑层。 e j b 分为三种：会话b e a n ( s e s s i o nb e a n ) 、实体b e a i l ( e n t i t yb e a l l ) 和消息驱 动( m e s s a g e d r i v e nb e a l l ) “。 会话b e a “ 会话b e a n 是一种非持久性、支持事务的服务器端组件，它表示同客户进 行的通常时间较短的通信会话。当客户结束与应用的会话时，会话b e a n 和它 所有的数据都不再可用。会话b e a n 包括有状态会话b e a f l 和无状态会话b e a i l 两种类型。有状态会话b e a n 只能为创建它的j a v a 客户服务，从而使得客户与 服务器之间相互关联。无状态会话b e a i l 用于建模无状态的服务，可以为多个客 户服务。 实体b e a n 实体b e a n 是持久的、以数据为中心的服务器端组件。这类b e a i l 用于建模 商业领域中的对象，一般情况下会储存在数据库中。根据如何管理持久性可以 把实体b e a n 分为两种。一种是b e a n 管理持久性( b m p ) 的实体b e a r l ，这种b e a n 需要b e a n 自己管理数据库中的关系和持久状态。b m p 开发者需要把数据库访 问逻辑代码直接写到b e a n 类中。另一种是容器管理持久性( c m p ) 的实体b e a n ， 数据库中的关系和持久状态管理将由e j b 容器完成。c m p 开发者不需要编写 数据库访问代码，e 用容器会根据相关的配置来处理数据访问。 消息驱动b e a n 消息驱动b e a n 是对异步消息做出反应的b e a l l 。主要用于接收、处理j a v a 客户通过j m s 发送的消息。这种b e a i l 用于建模企业内部消息中的过程、路由。 2 4j 2 e e 的容器 j 2 e e 服务器以容器的形式为组件提供底层服务。在部署过程中，组件被安 装到相应的容器中。容器为组件提供与部署、执行、生命周期管理、安全等相 关的服务。在容器中，j 2 e e 组件可以彼此之间( 或同其它容器中的组件) 进行 西南交通大学硕士研究生学位论文第9 页 通信。j 2 e e 标准定义了四种不同的容器为不同类型的组件提供服务。 a p p l e t 容器 如运行在客户机上的w 曲浏览器和j a v a 插件。 应用客户端容器 管理一个j 2 e e 应用中的全部应用客户端组件的执行。应用客户端及其相 关容器运行在客户机上。 w e b 容器 管理j 2 e e 应用中j s p 和s e 九，l e t 组件的执行，是服务器端容器。w e b 容器 中的组件可调用e j b 容器中的组件来完成复杂的商业逻辑。 e j b 容器 管理运行在其中的e j b 组件，是服务器端容器。只要满足j 2 e e 规范的e j b 放入该容器，马上就会被容器进行高效率的管理。e j b 容器除了为e j b 提供事 务处理、目录服务、持久性管理和安全服务外，还负责e j b 的部署、发布和生 命周期管理。 j 2 e e 的组件及其在容器中的分布如图2 3 所示。 图2 3 应用组件和j 2 雎容器 一个j 2 e e 服务器( 也叫j 2 e e 应用服务器) 可以支持一种或多种容器。如 t o c a t 、r e s i n 集成w e b 容器。j b o s s 、w e b s p h e r e 、w e b l o g i c 、j b o s s 等同时 集成e j b 容器和1 】r e b 容器。 西南交通大学硕士研究生学位论文第10 页 2 5j 2 e e 的优点与不足 j 2 e e 为搭建具有可伸缩性、灵活性、易维护性的系统提供了良好的机制。 其优点体现在： 保留现存的i t 资产。由于基于j 2 e e 平台的产品几乎能够在任何操作系 统和硬件配置上运行，所以用户现有的i t 资产能被保留使用。 高效的开发。j 2 e e 把一些通用的、繁琐的服务端任务交给中间件供应商 去完成。开发人员只关注如何创建商业逻辑，相应地缩短了开发时间。 支持异构环境。j 2 e e 能够开发部署在异构环境，有很强的可移植性。基 于j 2 e e 的应用程序不依赖任何特定操作系统、中间件、硬件。 可伸缩性。使用j 2 e e 开发的系统是松散耦合的，新开发的应用和服务 可以作为组件方便的加入到现有系统中。另外，j 2 e e 领域的供应商还提供了更 为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署，实 现可高度伸缩的系统，满足未来商业应用的需要。 但是，随着应用规模的越来越大，软件复杂性的越来越高，j 2 e e 的不足也 逐渐暴露出来。 应用系统的开发一般是基于过程的。通常由一组j s p 页面来实现一个业务 流程，流程控制的代码和业务逻辑的代码混杂在一起，j s p 页面中嵌入了大量 的j 越，a 语句。当系统业务流程发生改变时，就需要对多处代码进行修改，这 样非常不利于应用系统的扩展和更新。 j 2 e e 对于表现逻辑和业务逻辑并没有进行强制性的分离，虽然提出了用 j s p s e r v l e t 叮b 的结构来分离表现逻辑、流程控制和业务逻辑，但很多开发 人员还是把表现逻辑和部分业务逻辑都放在j s p 页面中，这j s p 的代码变得庞 大而复杂，开发人员无法有效地分工。 同时，企业级应用应该提供各种类型的界面。如采用h 瑚l 前端与、e b 方式的用户交互；采用w m l 与无线应用客户交互；采用以x m l 为基础的w e b 服务为供应商服务。这种情况下，尽管业务逻辑相同但表现逻辑却完全不同， 如何尽量实现代码的重用，避免重复劳动也是需要关注的问题。 西南交通大学硕士研究生学位论文第11 页 第3 章w e b 整体开发框架的实现策略 j 2 e e 本身只是一种广泛意义上的企业解决方案。多层j 2 e e 架构在提高软 件重用性和分解问题复杂性的同时，也使得代码庞大，层与层之间的控制关系复 杂。一些应用由于设计不合理，代码变得庞大混乱，难以维护和升级。另一方 面，现存的i t 资产无法得到有效保留。开发一个新的应用往往需要从头开始， 而无法直接利用一些现有的设计思想、系统架构以及代码。 因此，人们试图从已有的应用中总结经验，并将现有的技术进行组合，设 计一个合理的、能确保软件开发正常进行的整体开发框架。整体开发框架是 j 2 e e 平台和应用软件之间的一个中间件，它搭建了应用软件的骨架。开发人员 只需要在这个框架中填充与业务逻辑相关的部分就可以完成整个应用的开发。 具体来说，整个软件的非业务逻辑部分，即体系结构，系统各部分间的协 作和整合，公用服务功能等完全由开发框架来实现。开发者只需关注与实际需 求紧密相关的业务逻辑，实现与业务逻辑相关的代码，这样就可以把更多的精 力放在应用的业务逻辑上，保障业务需求的正确实现，避免了重复劳动。软件 开发变得有章可循，结构清晰，开发周期大为缩短，软件质量得到保证。软件的 可重用性、可维护性、可收缩性、简单性、稳定性也得到大大的提高。 本章将讨论w e b 整体开发框架的实现策略。根据j 2 e e 的五层体系结构，先 分别介绍w e b 层、业务逻辑层和数据持久层的实现策略，最后提出整体开发框 架的解决方案。 3 1 整体开发框架的设计目标 建立一个通用的基于j 2 e e 规范的w 曲框架，有以下几个评价指标“： 功能完善，能够满足用户业务所需要的各种功能。 通用性强。能够适应不同用户的不同需求，也就是框架要与具体业务 逻辑的耦合性要低。 分层结构，而且各层间的耦合性要低，以提高框架的柔性，能根据用 户不同的需求进行相应的改变。 西南交通大学硕士研究生学位论文第12 页 3 2m v c n v f o d e l 一e w c o n 仰1 1 0 f ) 设计模式 m v c 设计模式是呻g v er e e n s k a u g 于2 0 世纪8 0 年代为编程语言 s m a i i t a l k 8 0 发明的一种软件设计模式，近几年被推荐为j 2 e e 平台的设计模式。 所谓设计模式，就是一系列在实践中总结出来的可复用的面向对象的软件设计 方法，是经过多次验证的成功解的记录与提炼，表达的是关于软件的知识和经 验，是对知识、经验高层次的抽象“。 m v c 的引入，使得j 2 e e 的各层实现了真正的松散耦合。在m v c 模式中， 应用程序被强制分成三个部分：模型( m o d e l ) 、视图( v i e w ) 、控制器( c o n t r o l l e r ) 。 3 2 1m v c 模式的原理与结构 m v c 将系统划分为模型、视图和控制器三个部分。 用户请求 叠求横墅轶击 甚受赦帮更新夏求 虻用户柏八缸据件缩挖 制器 通批戢姑鬯焉 蕞摁 封肇矗用程序拉寿 峨麻对抗态妁查询 处理啦井漶授 通如砚蔼翼新 图3 1m v c 设计模式 把上图和j 2 e e 的多层体系结构联系起来，控制器组件和视图组件部署在 w 曲层，模型组件部署在业务逻辑层。下面详细介绍m v c 中的各部分“。 视图( e w ) ：视图是用户看到并与之交互的界面。视图向用户显示相关信 息，接收用户的输入数据，但并不进行任何实际的业务处理。视图可以向模型 查询业务状态，但不能改变模型。 模型( m o d e l ) ：模型是业务规则的制定，是应用程序的核心，它封装了应用 程序的数据结构和业务逻辑，集中体现了应用程序的状态。业务的处理过程对 其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。 l l 黧 西南交通大学硕士研究生学位论文 第17 页 此也有人把a c t i o n 划入模型组件一类。但是为了提高应用程序的灵活性和可重 用性，使系统层次清晰，s t r u t s 用户指南还是建议把“业务逻辑实现( 怎么做) ” 同“a c t o n 类( 要做什么) ”区分开来，将业务逻辑放在单独的j a v a 包或e j b 中， 以便于业务逻辑的重用。因此，把a c t i o n 划为控制器组件。 模型 s t n l t s 本身并没有提供模型组件。它主要是注重v 、c 部分的解决，m 部分 通常使用j a v a b e a n 表示系统的内部状态，根据系统的复杂度也可以使用e j b 。 因此s t r u t s 的模型层就可以用系统的业务逻辑层来充当。由于s t m t s 没有提供 业务逻辑的解决方法，因此，它被划为w 曲层的框架。 ( 2 ) s t r u t s 框架的工作流程 对于采用s t m t s 框架的w e b 应用，在w 曲应用启动时就会加载并初始化 a c t i o n s e r v l e t 。a c t i o n s e r v l e t 从s t m t s c o l l f i g x m l 文件中读取配置信息，把它们 存放到各种配置对象中，例如a c t i o n 的映射信息存放到a c t i o n m a p p i n g 对象中。 当a c t i o n s e r v l e t 接收到一个用户请求时，将执行如下流程，流程图如图 3 3 所示”“。 ( 3 ) s t r u t s 的基本组件“”圳 a c t i o n s e r v l e t 类 s t m t s 框架的核心组件是a c t i o n s e r v l e t 类，它充当整个框架的控制器。控 制器在处理一个请求时会完成以下任务： 将请求u r j 与适当的a c t i o n m a p i n g 进行匹配。 将请求映射到相应a c t i o n 类。如果这是特定a c t i o n 类的第一个请求， 它将初始化这个实例并且进行缓存。 创建或发现一个a c t i o n f o n n 实例，并将请求参数放入。 调用a c t i o n 类的e x e c u t c 方法获取数据或者执行业务逻辑。它将调用 a c t i o n 实例中的方法，并将a c t i o i l f o 珊b e a l l ， a c t i o n m 印p i n g ，r e q u e s t 和 r e s p x 西南交通大堂硕研究生学位论塞 篡；到 蘸垂鋈墓雾壤i i ? k 摧蒌藿妻翼墼秀一薹j 囊薹慧篓囊霎篓囊囊攀蠹二兰主矗墓 零鹱，夔蕈黉嚣蠢墓鬻；l l i 目 | 霎孽星囊霪露壅霪囊蠢璧孽妄| | i 搿? ，：7 | | | | 一j ；i i 薷l 浮荔震咿i “增衙鞴璧i 鹱丽臻楚弱驿姻麓蠢湔l t k 塑鄞蠢蠢善： 西镑取为组轰搿陇嚣涵：旧涯；再藿i i 萎掣叁篓襄熬囊娶； 蒌鬻曼 蕃￥摧；i i 冽秦警巢曼显态耍垂导仟。型惯娜噬膨雀善。芎蒿器的信星i 蓠嚣蚕 露骗籍麓l i 二；i 霸溺莲裴蠢| 繁羹箨撞j 铡篓霎笺墓酱艇觋型弼堑鬯丝藿i 薹。 弓螭l l i l 撄穰摧哐鋈蠹氆荔鬃墓西装鎏蒂嗡涩哩测罐；憎甚! i 陪l j 淄a 囔噶 性粤渐湍灌灌氢雾鞘；驯翌；装誊燮摹嘲强猁嵝焉鹱。 l t ! 董 ：= ：i 张蠡譬如“磷辎 鲥鞘鬟靼女i 超i ；墓鬻燃瑚惟淳j 剖县体的委攀囊黧翳骝 x 西南交通大学硕士研究生学位论文第1 9 页 a c t i o n f o 彻是j a v a b e a n ，这些b e a n 的属性名称与h t t p 请求中表单的名 称相对应。控制器将请求参数传递到a c t i o n f o f n l 的实例，然后将这个实例传送 到a c t i o n 类。可以从以下几个方面来理解a c t i o n f o 唧： a c t i o i l f o 衄表示h t t p 表单中的数据，可以将其看作是模型和视图的中 介，它负责保存视图中的数据供模型或者视图使用。 a c t i o i l f o m 是与一个或多个a c t i o n c o 曲g 关联的j a v a b e a n ，在相应 a c t i o n 的e x e c u t e 方法被调用前，a c t i o n f o 蛐会自动利用请求参数来填充自己。 a c t i o t l f o 肌是一个抽象类，用户必须通过继承来实现自己的具体类。 a c t i o n f o m 首先要进行初始化，然后调用v a i i d a t e 方法，检查请求参数的正确 性和有效性。如果通过v a l i d a t e 方法的验证，a c “o l l f o n n 将被作为参数传给具 体a c t i o n 类的e x e c u t e 方法以供使用。 a c t i o n 类 a c t i o n 类是控制器的一部分，我们通过继承a c t i o n 类来实现具体的执行类。 a c t i o n 类的功能一般都在e x e c u t e 方法中完成，主要涉及到以下几个方面“1 ： 辅助a c t i o l l f o h l l 进行表单数据的检查。 调用业务逻辑类的方法来执行必要的业务流程。 更新服务器端的b e a l l 数据，后续对象中可能会用到这些数据。 根据处理结果决定程序的去处，并以a c t i o n f o n a r d 对象的形式返回给 a c t i o n s e r v l e t 。 这里要强调是，a c t i o n 是一个控制器类，不应该用来处理业务的核心逻辑。 应该将业务逻辑封装到单独的j a v a b e a i l 或e j b 组件中，而a c t i o n 只负责错误 处理和流程控制。 a c t i o n f o r w a r d 类 a c t i o n 完成处理后，返回个a c t i o l l f o 刑a r d 类。这个类将决定处理结果 转发到的目的地。如果a c t i o l l f o r w a r d 为n u l l ，a c t i o s e r v l e t 假定响应产生了， 但不做任何事情。否则a c t i o n s e r v l e t 读入a c t i o l l f o n a r d ，重定向或者转发请 求到相应的资源。 e r r o r 类 e 九d r 类是s t m t s 中用以表示操作错误的类，包括封装了单个错误消息的 西南交通大学硕士研究生学位论文 第2 0 页 a c t i o n e o f 和提供容器的a c t i o l l e h 讲s 。视图可以使用标记访问这些类。 ( 4 ) s t m t s 的优点 s t m t s 跟t o m c a t ，t u r b i n e 等诸多a p a c h e 项目一样，是开源软件，使开发 者能更深入的了解其内部实现机制。 设计良好、功能强大的标记库，大大提高开发效率。 提供了灵活的体制来处理错误和异常，并对国际化有很好的支持。 实现了m v c 设计模式。 ( 5 ) s 咖t s 的缺点： 理解和使用框架有定的难度。 视图部分的精力主要集中在j s p 上，以x m l 等多种元素作为视图实现 的功能，需要进一步加强。 3 3 2j a t 0 框架 、 j a t 0 应用程序框架是i p l a l l e t 应用程序框架的旧名。它是一个成熟的、强 大的，基于j 2 e e 标准的面向于开发w 曲应用程序的框架。r a t d 结合了显示 字段、应用程序事件、组件层次、以页面为中心的开发方法以及m v c 和服务 到工作者( s e r v i c e - t o w o r k e r s ) 等设计模式”l 。 和s t r u t s 一样，它也不是一个模型层的应用框架，也就是说它不会直接提 供创建e j b 和w 曲s e n i c e s 等模型层组件的方法，但用它可以构造出访问模型 层组件的客户应用。j a t o 对大型的应用支持较好。但由于j a t o 不是业界标准， 目前还没有开发工具的支持，因此较少地应用到实际开发中。 3 3 3c o c o o n 框架 c o c o o n 是一个开源项目，是a p a c h e 组织的) 砷l 项目之一。它允许使用 x s l t ( x m ls t y l e s h e e tl a i l g u a g et r a n s f o n n a t i o n ) 转换动态发布x m l 内容。 c o c o o n 采用了流行的m v c 设计模式，用于构建内容、逻辑和表示在很大程度 上彼此分离的应用程序。 c o c o o n 的优点体现在：内容、逻辑和表示在很大程度上彼此分离；简化了 部分开发工作：c o c o o n 可以容易地同r d b m s 、l d a p 以及本机讧l 数据库 之类的数据源交互。但c o c o o n 把所有的数据作为s a x ( s i m p l ea p if o rx m l ) 事 西南交通大学硕士研究生学位论文 第2 1 页 件来处理，任何非x m l 的数据都要转变成x m l 描述，给用户定制应用逻辑 带来了不便，并且页面导航，整体的请求分派不明显。 3 4 业务逻辑层的实现策略 从前面对s n l j t s 的介绍中不难看出，作为w 曲层的框架，s 咖t s 的工作主 要体现在页面的组织以及业务流程的控制上。虽然把业务逻辑作为模型单独的 分离出来，并在a c t i o n 对象中调用业务逻辑的代码，但s t n j t s 并没有提出业务 逻辑的具体实现方法。 这一节将探讨业务逻辑层的实现策略：j a v a b e a n 和会话b e a n 。 3 4 1j a v a b e a n 或普通j a v a 类封装业务逻辑 j a v a b e a i l 或普通j a v a 类都是以功能的实现为核心。 j a v a b e a i l 的结构在j 2 e e 规范中有详细的定义。它分成两种形式：可视化 和非可视化。w e b 应用一般不使用可视化的j a v a b e a n ，因此这里主要介绍非可 视化的j a v a b e a n 。 j a v a b e a n 或普通j a v a 类没有更多的附加功能，也不能由容器提供某些特殊 的服务，在大型的、分布式的应用环境中，事务处理、安全性、资源分配等方 面都需要开发者自己实现。因此用j a v a b e a n 或普通j a v a 类来实现业务逻辑就 显得有些力不从心。但是对于小型的项目来说，j a v a b e a l l 或普通j a v a 类实现简 单，运行效率较高，不需要添加含有e j b 容器的应用服务器，只需要一台w 曲 服务器就可以让系统正常运行。“。 3 4 2s e s s i o n b e a n 封装业务逻辑 e j b 定义了两种不同类别的企业级b e a i l ：会话b e 柚( s e s s i o n b e a n ) 和实体 b e a n ( e n t i t y b e a n ) 。s e s s i o n b e a i l 代表调用它的客户端要它完成的工作，业务逻 辑代码在这里实现。e n t i t y b e a l l 作为处理底层持久性数据的组件模型，将在下 一章介绍数据持久层的实现技术时加以介绍。 会话b e 锄是一种非持久性、支持事务的服务器端组件。它包括有状态会 话b e a l l 和无状态会话b e a n 两种类型”“1 。 有状态会话b e 锄只能为创建它的j a v a 客户服务。有状态会话b e a n 定义实 例变量，以用于保存会话过程中的会话数据，从而使得客户与服务器之间相互 西南交通大学硕士研究生学位论文第2 2 页 关联。这种特性使得有状态会话b e a n 作为客户的扩展、在e j b 服务器上维护 会话数据并为客户完成需要的任务。有状态会话b e a n 用于建模代理、角色之 类的商业概念，这里的代理、角色是针对特定客户的。 无状态会话b e a n 可以在多个客户之间共享。这种机制给无状态会话b e a n 实例更多的弹性，但同时也无法在e j b 服务器中维护会话数据。无状态会话 b e a n 中，方法调用之间没有什么关系。每个方法调用是无状态的、类似于j a v a 类中的s 诅t i c 方法。无状态会话b e a n 用于建模无状态的服务。 e j b 组件的运行需要有e j b 容器的支持，e j b 容器负责管理e j b 组件的生 命周期、持久性、事务属性和安全特性等，这为开发者提供了方便。但这种方 便是以消耗更多的系统资源，增加更长的响应时间为代价换来的。同时，e j b 本身的复杂性也使开发者在学习和开发时需要花费更多的时间。 3 5 数据持久层的实现策略 j 2 e e 五层体系结构引入单独的数据持久层来解决数据持久化的问题。这 样，所有与业务数据持久有关的操作，如数据库的访问，数据的增加、删除、 修改、查询等，都在数据持久层里实现。数据持久层提供的服务完全抽象并且 隐藏了使用数据源的物理细节。当数据源更改，数据库移植，数据结构改变等， 仅对数据持久层修改即可。 本节将对数据持久层的几种主要实现技术进行介绍和比较： 3 5 1j d b ca p l j d b c 是j a v ad a t a b a s ec o r h l e c t i v 酊的缩写。j d b c 规范使j a v a 程序可以通 过统一标准规范的j d b ca p i 来与不同的数据库通信。j d b c 规范