（计算机应用技术专业论文）基于mvc模式的struts框架在客户售后服务管理系统中的应用.pdf

摘要 近年来，随着网络技术和h t e m e t 的迅速发展，基于b m w s c r s e r v e r 结构的w e b 应 用，因其具有易用性、通用性和良好的可扩展性等优点而发展迅速，正逐渐成为实现企 业应用信息系统的主流技术。而开发一个w e b 应用系统是一项浩大的工程，要求设计者 能够提出合理的系统架构。合理的系统架构可以减少开发及维护系统所用的资源、提升 工作效率。因此，在w e b 企业级应用系统开发过程中，设计模式的选定和应用系统架构的 构建是一项重要内容。目前，在基于j 2 髓架构开发、e b 应用的技术基础上，结合 m v c f m o d c l 一v i e w c o n t r o l l e n 结构的方式来构建、e b 应用系统是一种较好的w e b 应用实 现方案。s t r u t s 框架是m v c 设计模式的一个应用实例，应用s t n l t s 框架可以减轻设计和 开发大型企业级软件的负担，使设计人员和编程人员在较短的时间里就能够开发出系统 原型。 本论文首先对客户售后服务管理系统的特点和功能需求进行了全面的分析，选用 j 2 e e 体系结构作为客户售后服务管理系统结构的设计方案。然后深入剖析m v c 模式的 设计思想，探索了基于m v c 模式开发w e b 应用程序的优缺点。继而着重实践了应用 s t n l t s 框架开发基于m v c 模式的w e b 应用程序的全过程。通过实践证明，在使用s t r u t s 框架进行开发以浏览器( b f o w s c r ) 为客户端的应用程序时，s t m t s 框架的确能够帮助我们 快速开发出高品质的软件。 关键词：设计模式；框架：m v c ：s t n l t s 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究 工作及取得的研究成果。据我所知，除了文中特别加以标注和致 谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果， 也不包含为获得东北师范大学或其他教育机构的学位或证书而使 用过的材料。与我一同工作的同志对本研究所做的任何贡献均已 在论文中作了明确的说明并表示谢意。 学位论文作者签名：团盘壁日期 。w 口6 s ) s 学位论文版权使用授权书 本学位论文作者完全了解东北师范大学有关保留、使用学位 论文的规定，即：东北师范大学有权保留并向国家有关部门或机 构送交学位论文的复印件和磁盘，允许论文被查阅和借阅。本人 授权东北师范大学可以将学位论文的全部或部分内容编入有关数 据库进行检索，可以采用影印、缩印或其它复制手段保存、汇编 学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文作者签名： 日期： 学位论文作者毕业后去向： 工作单位： 通讯地址： 指导教师签名：虽址 日期：趔i ：! 电话： 邮编： 1 1 课题研究背景 第一章引言 在计算机软件发展的早期，一个应用系统往往是由一整块代码组成的。随着人们对 软件需求的不断增加，软件变得更加复杂，更加庞大，开发的难度也越来越大。 近年来，随着网络技术的迅速发展和j 2 e e 平台的广泛应用，基于b s 的多层w e b 体系结构逐渐发展成熟起来，b s 体系结构猛烈冲击c s 体系结构，大有取而代之的趋 势。在现代的软件开发中，多层w e b 应用的开发已成为主流。但是，在多层w e b 体系 结构的设计中，仍然存在着程序可重用程度低、维护工作繁琐、应交能力较弱等不足。 同时，多层w e b 应用软件需要面对复杂的网络环境、多样化的用户需求、灵活的业务 模式、复杂的业务流程、众多的组织机构及层次和角色分工等问题，在业务和技术上也 是复杂多变的。因此，如何组织应用程序以实现简单高效的程序编写、升级、维护和扩 展，是当前i l l t e m e t 技术发展的热点之一，也是一个很值得探讨的研究课题。 随着面向对象技术的不断发展，许多系统提供了与应用相关的面向对象框架供开发 人员使用，以简化应用程序的开发。框架是可重用的、“半成品”应用程序，可以在它的 基础上开发特定的应用程序。一个框架由组件的集合构成，这些组件为解决目标领域问 题提供了可重用的体系结构。利用这个可重用的体系结构，使得这些问题的解决变得十 分容易。基于j 2 e e 平台的m v c 模式为采用j 2 e e 技术的w e b 应用程序开发提供了一 个可重用的体系结构。 m v c 模式是专为交互式系统应用开发所设计的一种设计模式。正是由于m v c 模 式在交互式系统开发中所体现的强大优势，而被开发人员逐步引入到j 2 e e 体系之中， 成为j 2 e e 进行交互式应用开发的重要模式。特别是s 廿u t s 架构更是w e b 应用开发的一 个非常重要的设计模式。 框架s t n l t s 是a p a c h c 组织的一个项目，像其他的a p a c h e 组织的项目一样，它也是 开放源码项目。s t m t s 是一个比较好的m v c 框架，主要采用大多数开发者熟知的 j a v a b e a i l ，j a v as e r v e rp a g e ( j s p ) ，s e r v l e t 等标准技术，对m v c 设计模式的三个部分提 供了对应的实现组件，它的目的是为了帮助开发人员减少运用m v c 设计模式开发w e b 应用的时间【lj 。其中对应用程序的用户界面表示和数据的后端逻辑处理代码进行了抽象， 整合了s e r v i e t s 和j s p 在w 曲应用开发上的优势以建立灵活性好、扩展性强、复用程度 高的应用系统。 1 2 本文的主要研究内容 本文的重点是如何基于s t m t s 框架实现对w e b 层的开发。主要完成了下面几项工作： 1 j 2 e e 平台的研究。 2 m v c 设计模式的研究。对m v c 设计模式进行了深入的研究，通过对w e b 应用 开发常用模式的分析与对比，深刻理解了该模式的模型、视图、控制器三部分在构成 w c b 应用程序框架中所起的作用，并总结出使用此模式所存在的优势与不足。 3 s t n l t s 框架的研究。s 仉l t s 是实现m v c 模式的一个优秀的应用框架。本文对该框 架的整体结构及处理流程进行了深入的分析及研究，并对s m l 坞的开发流程作了总结。 4 通过对m v c 设计模式及s t m t s 框架的深入研究，以及对多层w e b 体系结构各层 实现方式的分析与对比，最终总结出基于j 2 e e 平台开发w e b 应用程序的技术方案，并 成功的应用到实际开发项目中，从而得到比较合理的基于s t n l t s 框架的w e b 应用开发的 技术组合。 1 3 论文的组织 第一章引言部分简要阐述了本课题的研究目的和意义，并介绍了课题研究的主要内 容。 第二章主要介绍了j 2 e e 平台的体系结构即四个层次以及j 2 髓的相关核心技术。 第三章介绍了设计模式概念并详细介绍了m v c 设计模式。详细分析了该模式的三 个组成部分的主要功能，并总结了该模式的优势与不足。 第四章主要介绍基于m v c 模式的w e b 应用框架s t m t s 。对s 仃1 l t s 框架的体系结构 和处理流程进行了详细的阐述，并介绍了使用s t m t s 框架的开发流程以及应用此框架的 优势和不足。 第五章利用s t m t s 框架实现了一个客户售后服务管理系统，用实例说明了s t m t s 框 架的应用方法，并验证了该方法的正确性。 第六章总结与展望。对本文中所做的工作进行总结，并对目前新技术的发展做了展 望。 组件包括j s p 页面和s e r v l e t s 。w e b 层也可以包括一些j a v a b e a t l s 。w e b 层主要用来处理 客户请求，调用相应的逻辑块，并把结果以动态网页的形式返回到客户端。 r 一一一一一一一1 客户层 ： w e b 层： 商业逻辑层 ；企业信息系统层 r、 浏览器 e j b 容器 、 、。一 l p w o j s p 数 h t “ 邑 e车 e j b e j a v 8 j 趼 i a p p l “ i、， i f e j b 】 车冷 一一、l ，、 k s 刊“ f a p p “c “o jg k 、 lc e l 数 i 据 i a p p e c a “ j 2 e e j 2 e e i p l a 惭m p l 札f o f m 邑 i c h e n t i c o n t a i n e f ， 、 j 窖尸机 j 2 e e 服务器 e i s 服务器 图2 1j 2 e e 多层结构的应用程序体系结构 3 业务层饵u s i n e s st i e r ) 业务层也叫日b 层或应用层，它由日b 服务器和日b 组件组成。一般情况下许多 开发商把w e b 服务器和h b 服务器产品结合在一起发布，称为应用服务器。m b 层用 来实现企业级信息系统的业务逻辑。这是企业级应用的核心，由运行在业务层中的日b 来处理。一个b e a n 从客户端接收数据并进行处理，然后把数据送到企业信息系统层存 储起来。同样，一个b e a n 也可以从企业信息系统取出数据，发送到客户端程序。业务 层中的口b 要运行在容器中，容器解决了底层的问题，如事务处理、生命周期、状态管 理、多线程安全管理、资源池等。 4 企业信息系统层( e n t e r p r i s em f o 彻a t i o s y s t e mt i e r ) 处理企业系统软件，包括企业基础系统、数据库系统及其他遗留的系统。j 2 e e 将 来的版本支持连接架构( c o n n e c t o ra r c h i t e c t u r c ) 。它是连接j 2 e e 平台和企业信息系统层 的标准a p i 。 其中，业务层和w e b 层共同组成了三层j 2 e e 应用的中间层，其他两层是客户端层 和存储层或企业信息系统层。 2 3j 2 e e 的核心技术 为实现企业级分布式应用，j 2 e e 定义了丰富的技术标准，符合这些标准的开发工 具和a p i 为开发企业级应用提供支持。这些技术涵盖数据库访问、分布式通信、安全等。 为分布式应用提供支持的多方面。 4 3 1 设计模式 第三章m v c 设计模式 设计模式的概念最初来自于城市建筑专家a l r i s t o p h c r 触e x a i l d e r 对建筑模式的定 义：“每一个模式描述了一个在人们周围不断重复发生的问题，以及该问题解决方案的 核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。”在软件开发中我们 也经常会遇到这样的问题：我们不断重复地做着不同项目中相似的设计工作，我们已经 解决过了一个这样的问题但就是不能确切知道是在什么地方或具体怎么解决的? 如果 我们能记起以前问题的细节和解决方法，我们就可以复用以前的经验而不需要重新设计 它【1 3 】。 把以前经常遇到的问题进行归纳总结，得出通用的解决方案，就形成了设计模式。 尽管a l c x a i l d c r 所指的是城市和建筑模式，但他的思想也同样适用于面向对象的软件开 发中。只是在面向对象的解决方案里，我们用对象和接口代替了墙壁和门窗，两类模式 的核心都在于提供了相关问题的解决方案。 一般而言，一个设计模式有四个基本要素( 1 4 】： 1 模式名称俾a t t e mn 枷e ) 一个助记名，它用一两个词来描述模式的问题，解决方案和效果。如果有一个统一 的模式词汇表，开发人员就可以讨论模式并在编写文档时使用他们。模式名可以帮助我 们思考，便于我们与其他人交流设计思想以及设计结果。 2 问题( p r o b l e m ) 描述了应该在何时使用设计模式。它解释了设计问题和问题存在的前因后果，它可 能描述了特定的设计问题，也可能描述了导致不灵活设计的类或对象结构。有时候，问 题部分会包括使用模式必须满足的一系列先决条件。 3 解决方案( s o l u t i o n ) 描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式 就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计 或实现，而是提供设计问题的抽象描述和怎么用一个具有一般意义的元素组合( 类或对 象组合) 来解决这个问题。 4 效果( c o n s e q u e 3 2j s p m o d e l l 与j s p m o d e l2 随着网络技术的不断发展，基于w e b 的应用程序已经成为当前企业应用程序开发 的主流，应用j 2 e e 平台技术开发w e b 应用程序，有两种常用的设计模式：j s pm o d e l l 和j s p m o d e l2 。 3 2 1j s pm o d e i l 在使用j a v a 技术建立w e b 应用的实例中，由于j s p 技术的发展，很快这种便于掌 握和可实现快速开发的技术就成了创建w e b 应用的主要技术。j s p 页面中可以非常容易 地结合业务逻辑( j s p ：u s c b e a n ) 、服务端处理过程( i s p ：s a j p l e t ) 和h r m u ) ，在j s p 页面中同时实现显示、业务逻辑和流程控制，从而可以快速地完成应用开发。现在很多 的w e b 应用就是由一组j s p 页面构成的。这种以j s p 为中心的开发模型可以称之为 m o d e l1 ( 如图3 1 所示1 。 l r e 叩e n 肿 召 4 摹 r e o 口 器 1 2 ，、 3 ( j “a b e “ ) _ 、一 a p p 如出o n s e e f 图3 1j s p m o d e l l 体系结构 m o d e l l 的基础是j s p 文件。它从h t t p 的请求中提取参数，调用相应的业务逻辑， 处理m 四会话，最后生成王册文档。一系列这样的j s p 文件形成一个完整的m o d e l i 应用。 在m o d e l l 中，j s p 页面独自响应请求并将处理结果返回客户。总的看来，这个模 型的好处是简单，可以很好的满足小型应用的需要，但是它把业务逻辑和表现混在一块， 不能满足大型应用的要求。大量使用m o d e l l ，常常会导致页面被嵌入大量的s c r i p t 或 j a v a 代码。特别是当需要处理的商业逻辑比较复杂时，情况会变得非常的严重。对于j a v a 程序员来说，这不算大的问题。但如果开发者是前端界面设计人员，则代码的开发和维 护将出现困难。在任何项目中，这样的模式总会导致定义不清的响应和项目管理的困难。 因此这种开发模式在进行快速和小规模的应用开发时，是有优势的，但从工程化的 角度考虑，它存在一些不足之处： 1 应用的实现一般是基于过程的，一组j s p 页面实现一个业务流程，如果要进行改 动，必须在多个地方进行修改。这样非常不利于应用扩展和更新。 8 2 由于应用不是建立在模块上的，业务逻辑和表示逻辑混合在j s p 页面中没有进行 抽象和分离。所以非常不利于应用系统业务的重用和改动。 为了解决这些问题，就出现了另一种开发模式，那就是m o d e l2 。 3 2 2j s pm o d e l2 m o d e l2 f 】6 1 ，】表示的是基于m v c 模式的框架f 如图3 2 所示) 。m o d e l ”代表应用的业 务逻辑( 通过j a v a b c a i l ，u b 组件实现) 。“v i e w ”代表应用的表示面( 由j s p 页面产生) 。 “c o n t m l l c r 是提供应用的处理过程控制( 一般是一个s e r v l e t ) 。通过这种设计模型把应用 逻辑、处理过程和显示逻辑分成不同的组件实现。这些组件可以进行交互和重用，从而 弥补了m o d e l l 的不足。 田 r e q u e s t l 呲0 1 l 蓉 ls m d e t i 蠹l 2 呷。蛐 器1 。1 哩e 撒 ， li e 呐 孓，、 f h o 口o m c j s p 7 一1 a ，一n c 也m s e w e r e n 置恶；篮嚣孑“ 图3 2j s p m 0 d e l2 体系结构 m v c 方法采用了j s p 和s e r v l e t 方法的最佳特性，使这两种技术可以协同工作。 s e r v l e t 是处理层( 控制器) ，它接收请求，很像m o d e l1 架构中j s p 页面所做的那样，并 确定如何满足那些请求。这就意昧着，s e r v l e t 控制输入的请求和输出的回应。j s p 页面 是显示层( 视图) ，不包括任何业务逻辑脚本，它只是将数据传送到s e n r l e t ，并接收和显 示返回的数据。 该架构的优势应该是很明显的。首先，它将计算和显示清楚地分开了，在j s p 页面 上没有出现处理过程，在s e r v l e t 或商业逻辑中没有数据格式。这种分离的另一个好处 是j a v a 程序员可以专注于s e r v l e t 代码， r r m l 编写者可以专注于j s p 。第二点，控制 器s e l e t 做页面上的所有的决定。在页面和逻辑中不会出现任何决策，这就提高了一 个应用程序的性能和可扩展性，因为请求可以被导向架构的不同的组件，甚至是不同的 服务器。 m v c 模式在交互式系统开发中具有强大的优势，因此被开发人员逐步引入j 2 e e 体 系之中，成为j 2 e e 进行交互式应用开发时，特别是w e b 应用开发时的一个非常重要的 设计模式【1 8 】。下面就将对m v c 设计模式进行详细的介绍。 3 3 m v c 设计模式 9 一1j。-!口日 3 3 1 什么是m v c 设计模式 m v c 是一种目前广泛流行的软件设计模式| 1 9 】。近来，随着j 2 e e 的成熟，它正成为 j 2 e e 平台上推荐的一种设计模式。随着网络应用的快速增加，m v c 模式的设计思想也 影响着w e b 应用的开发，它为开发者理解和分析应用模型提供最基本的分析方法、 清晰的设计框架和规范的依据。 3 3 2 m v c 的组成 m v c 把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离， 将w e b 应用分为三层：视图层、控制层、模型层，也称为视图e w 、控制器c o n t r o l l e r 、 模型m o d e l l 2 l ! 盈l 。 1 视图f v i e w ) 视图是用户看到并与之交互的界面。视图向用户显示相关数据，并能接收用户的输 入数据，但是它并不进行任何实际的业务处理。视图可以向模型查询业务状态，但不能 改变模型。视图还能接收模型发出的数据更新事件，当模型发生改变时，视图也将随之 改变，以维持系统数据的一致性，从而对用户界面进行同步更新。 在m v c 模式下，通常的设计前提是界面任务较小。当然视图也应该具有一定的功 能性并遵守可用性的约束，但视图晁面不应当处理数据。事实上，视图的每一部分都只 能包含采集数据的逻辑，并把采集到的数据传递给设计模式中的其他组成部分进行处 理。 对老式的w e b 应用程序来说，视图就是由h 跏l 元素组成的界面，在新式的w e b 应用程序中，m m l 依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它 们包括m a c r o m e d i af 1 a s h 和以及m l ，x m l s l ，w m l 等一些标识语言和w e b s e n r i c e s 。 如何处理应用程序的界面变得越来越有挑战性。m v c 一个大的好处是它能为应用 程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存 储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方 式。 2 控制器( c o n 仃o l l e r ) 控制器是联系模型与视图之间的纽带，控制模型和视图之间的交互过程。它获取并 翻译用户输入的动作，指定执行该动作的模型，或者根据用户的输入和执行的结果来选 择下一个视图。 控制器封装的是外界作用于模型的操作。通常，这些操作会转发到模型上，并调用 模型中相应的一个或者多个方法。一般控制器在模型和视图之间起到了沟通的作用，处 理用户在视图上的输入，并转发给模型处理。这样模型和视图两者之间可以做到松散藕 合，甚至可以彼此不知道对方，而由控制器连接起这两个部分。例如，当、v c b 用户单 击w 西页面中的提交按钮发送来删l 表单时，控制器接收请求并调用相应的模型组 件去处理请求，然后调用相应的视图来显示模型返回的数据。 1 0 其次，分离数据和显示，实现了模型的可移植性。一方面，分离数据和其表示，使 得添加或者删除一个用户视图变得很容易，甚至可以在程序执行过程中动态的进行用户 视图的更新。模型和视图能够单独的开发( 即业务逻辑和用户表现的分离) ，增加了程序 了可维护性，可扩展性，并使测试变得更为容易。另一方面，将控制逻辑和表现界面分 离，允许程序能够在运行时根据工作流，用户习惯或者模型状态来动态选择不同的用户 界面。 大部分w e b 应用程序都是用像a s p ，p h p 等过程化语言来创建的。其将像进行数 据库访问查询的数据层代码和像h ：眦l 这样的表示层代码混在一起。经验比较丰富的 开发者会将数据从表示层分离开来，但这通常不是很容易做到的，这需要精心的计划和 不断的尝试。m v c 从根本上强制性的将它们分开。尽管构造m v c 应用程序需要一些 额外的工作，但是它给开发者带来的好处是无庸质疑的。 再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。 一个应用的业务流程或者业务规则的改变只需改动m v c 的模型层。 因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变应用程序的数 据层和业务规则。如果需要数据库从s q l s e r v e r 移植到o r a d e ，或者改变的基于r d b m s 数据源到u ) a p ，开发人员只需改变他的应用模型即可。一旦开发人员正确的实现了模 型，不管数据来自数据库或是u ) a p 服务器，视图将会正确的显示它们。由于运用m v c 的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设 计思想开发者能构造良好的松耦合的构件。 3 3 4m v c 模式的缺点 m v c 的缺点在于它没有明确的定义，所以一个开发人员完全理解m v c 并不是很 容易。使用m v c 也需要精心的计划，由于它的内部原理比较复杂，所以开发者需要花 费相当可观的时间去考虑如何将m v c 运用到应用程序之中。 同时由于模型和视图要严格的分离，这样也给调试应用程序到来了一定的困难。每 个构件在使用之前都需要经过彻底的测试。一旦构件经过了测试，就可以毫无顾忌的重 用它们了。 还有开发m v c 系统比简单的j s p 开发要复杂许多，它需要更多的时间学习和掌握。 同时新东西的引入会带来新的问题，在选择m v c 开发模式时必须仔细考虑这下问题： 1 必须基于m v c 组件的方式重新思考和设计应用结构。原来通过建立一个简单的 j s p 页面就能实现的应用现在变成了多个步骤的设计和实现过程。 2 所有的页面和组件必须在m v c 框架中实现，所以必须进行附加的开发工作。 3 m v c 本身就是一个非常复杂的系统，所以采用m v c 实现w e b 应用时，最好选 一个现成的m v c 框架，在此之下进行开发，从而取得事半功倍的效果。现在有很多可 供使用的m v c 框架，s t m t s 就是一个不错的m v c 的应用框架f 2 3 t 。 户请求，利用配置的a c t i o n m a p p i n g 对象把请求映像到a c t i o n 处理器对象进行处理。 a c t i o n 处理对象访问a c t i o n f o r i n 中的数据，处理和响应客户请求，它还调用后台的b e a n 组件，这些组件封装了具体的业务逻辑。 视图梗型 控带十器 h t t pa c 妇 r e q m n c o 心口i k r f 甜m b u o i m $ i o i c a c h o f 口e 州e ta c h o n i 黼岫雌e 1s 眦”o 蚯s 州i r v k wm o d e l j s pj a m b e m o re j b h t t p 图4 1s 仇l t s 框架与m v c 模式的映射 3 模型( m o d e l ) 组件 m v c 系统中的m o d e l 部分从概念上可以分为两类一系统的内部状态和改变系统状 态的动作。s t n l t s 通常使用一组j a v a b c a n 表示系统的内部状态，根据系统的复杂度也可 以使用像e n t i t v 胁和s e s s i o n b 等组件来实现系统状态。s t m t s 为m o d e l 部分提供了 a 硝o n 和a c t i o n f 0 n n 对象：所有的a c t i o n 处理器对象都是开发者从s t n l t s 的a c t i o n 类 派生的子类。a c t i o n 处理器对象封装了具体的处理逻辑，调用业务逻辑模块，并且把响 应提交到合适的v i e w 组件以产生响应。s t m t s 提供的a c t i o n f 0 n n 组件对象，它可以通 过定义属性描述客户端窗体数据。开发者可以从它派生子类对象，利用它和s t n l t s 提供 的自定义标记库结合可以实现对客户端的窗体数据的良好封装和支持，a c t i o n 处理器对 象可以直接对它进行读写，而不再需要和r e q u e s t 和f c s p o n s e 对象进行数据交互。通过 a c t i o n f o 肋组件对象实现了对e w 和m o d e l 之间交互的支持。s t n l t s 在实现时把做什 么( a c t i o n ) 和如何做( 业务逻辑) 分离，这样可以实现业务逻辑的重用。 4 5s t m t s 的基本组件包 整个s t r i l t s 大约有1 5 包，近2 0 0 个类所组成吼丛1 ，而且数量还在不断的扩展。在此 我们不能一一介绍，只能列举几个主要的简要的介绍一下。下表说明了目前s t m t sa _ p i 中基本的几个组件包，包括a c t i o n ，a c t i o n s ，t a 酉i b 。图4 2 则显现了这几个组件包之间的关 系。其中a c t i o n 是整个s t n l t sf | 锄e w o r k 的核心。 o r g a p a c h e s t m t s a c t i o n 基本上，控制整个s 仇l t s 胁m e w o r k 的运行的核心类、组件都在这个 包中，比如我们上面提到的控制器a c t i o n s e r v l e t ，a c t i o n ，a c t i o n f o 皿， a c t i o n m a p p 曲g 等等。s t n l t s1 _ 1 比1 0 多了d y n a a c t i o n f 0 皿类。增加了 动态扩展生成f 0 咖b e a n 功能。 o r g a p a c h e s m l t s a c t i o n s 这个包是主要作用是提供客户的h t t p 请求和业务逻辑处理之间的特 定适配器转换功能，而1 0 版本中的部分动态增删f r o m b e a n 的类，也在 s t 八l t s l 1 中被a c t i o 包的d y i l a a c t i o n f 0 册组件所取代。 o 唱印a c h e s 仃u t s t a 舀i b 这不是一个包，而是一个客户标签类的集合。下面包括b e a nt a 擎， h t m lt a g s ，l 0 9 i c1 a g s ，n c s t e dt a g s ，t c m p l a t et a g s 这几个用于构建 用户界面的标签类。 0 r g a p a c h e s t n l t s u t i l s t m t s 为了更好支持w c b 叩p l i c a t i o n 的应用，统一了一些常用服务的 支持，比如c o n e c d o np l 和m e s s a g cs o u r c e 。 o r g 印a c h e s t n l t s t a g l i b 这不是一个包，而是一个客户卷标类的集合。下面包括b c 趾t a g s ， h 州l t a g s ，l o 百ct a g s ，n e s t e dt a 盼t c m p l a t et a g s 这几个用于构建用户 接口的卷标类。 o r g a p a c h e s 饥l t s v a l i d a t o r s t r u t s1 1 舶m e 、r k 中增加了v a l i d a t o rf r a m e w o r k ，用于动态的配置 f b m 窗体的验证。 图4 2s t m t s 的基本组件关系图 对于s t n l t s 如何控制、处理客户请求，让我们通过对s t n l t s 的四个核心组件介绍来 具体说明。这几个组件就是：a c t i o n s e n r l e t 、a c t i o na a s s e s 、a 吐i o nm a p p i l l g ( 此处包括 a c t i o n f o r w 缸m 和a c t i o n f r o mb e 卸。 4 5 1 s t m t sa c t i o n s e n r l e t a c t i o n s e l e t 继承自j a v a x s e r v l e h l t p h t t p s e r v l e t 类，其在s t n l t s 触m e w o r k 中扮演 的角色是控制器，参看上面的“s t m t s 体系图”。控制器a c t i o n s e r v l e t 主要负责将客户的 h r r p 请求信息组装后，根据配置文件的指定描述，转发到适当的处理器。按照s e r v e l t 的标准，所有的s e r v l e t 必须在、v e b 配置文件( w e b x m l ) 声明。同样，a c t o i i l s e r v i e t 必须 在w e b a p p l i c a t i o n 配置文件( w e b x i i l l ) 中描述。 当用户向服务器端提交请求的时候，实际上信息是首先发送到控制器a c t i o n s e r v l e t ， 一旦控制器获得了请求，就会将请求信息传交给一些辅助类( h e l pd 嬲s e s ) 处理。这些辅 助类知道如何去处理与请求信息所对应的业务操作。在s t m t s 中，这个辅助类就是 o r g a p a c h e s t n l t s a c t i o 丑a c i 衄。通常开发者需要自己继承a c i t o n 类，从而实现自己的 a c t i o n 实例。 4 5 2 s t r u t sa c t i 加c i a s s 酷 a c t i o n 类所作的工作，正如它的名称一样，就是具体的业务操作。a c t i o n 类中最为 常用的是e x e c u t e ( ) 方法。 调用这个a d i o 实例的e x e c u t c ( ) 方法。s t n l t sf r a m e w o r k 为应用系统中的每一个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 ( ) 方法，因为a c t i o n 类在默 认情况下是返回n u u 的。 4 5 3 s t n i t sa c t i o nm a p p i n g 上面讲到了一个客户请求是如何被控制器转发和处理的，但是，控制器如何知道什 么样的信息转发到什么样的a c t i o n 类呢? 这就需要一些与动作和请求信息相对应的映 射配置说明。在s t n l t s 中，这些配置映射信息是存储在特定的x m l 文件 ( s t m t s c o n f i g x m l ) 。 这些配置信息在系统启动的时候被读入内存，供s t m t sf r a m e w o r k 在运行期间使用。 在内存中，每一个 元素都与o r g a p a c h e s t n l t s a c 曲n a 讹n m a p p i n g 类的一个实 例对应。下面就显示了一个登录的配置映射。 它将 j s p 页面和处理这个j s p 页面的a c t i o n 对象对应起来。 t ”e ： 对应的a c t i o 子类的完整类名。 n a m e ：对应的a c l i o n f o 吼的名称。他与下面将描述的( f 0 珊- b e a n 元素的n 锄e 属性相应。 s c d p e ：这个属性表示相对应的a 口i o n f o 加b e a 的s c d p e 属性。它的值可以是 “p a g c ”、“r e q u e s t ，、“s e s s i o n ”和a p p l i c a t i d n 。分别对应j a v ab e 皿的“p a g e ”、“r c q u e s t ”、 “s e s s i o n ”和“a p p l i c a t i o n ”属性。 k p u t ：这个属性表示如果对应的a c t i 叫f o 加的v a l i d a t e 方法返回值的a c t i o n e n o r s 非空，即a c t i o n f 0 n n 的属性没有通过校验，则跳转到当前的页面。 v a l i d a t e ：是否调用f o 瑚b e 强的v a l i d a t “) 方法来验证，关闭它之后就不会报出错 误信息了。t r u e 表示需要调用v a l i d a t e 方法：f a l s e 表示不需要调用v a l i d a t e 方法。 f o 研盯d ：定义可能的跳转路径。n 锄e 属性表示a c t i 彻类的e x e c u t e 方法中，生成 的返回结果时的参数；p a t h 表示将要跳转到的页面的路径。 上面的配置表示：当可以通过l o g o 吣t i o n d 0 提交请求信息的时候，控制器将信息 委托c o m t e s t l o g o n a c t i o n 处理。调用l d 9 0 n a c t i o n 实例的e x e c i l t e ( ) 方法。同时将m a p p i n g 实例和所对应的l 0 9 0 n f o n nb e a i l 信息传入。其中n 锄e = l 0 9 0 n f o 衄，使用的f o n n - b e a n 元素所声明的a d i o n f o mb e a i l 。有关f o r i n - b e a l l 的声明如下显示： 有两个属性： n a m e ：这个a c t i o n f o 咖的名字，他与被j s p 页面中的 元素的n a m e 属性应该是相同的。比如，如果在一个j s p 页面中需要生成一个a c t i o n f o 皿对象，这 个对象的名字( 就是a m e 属性) 是“l d 舀n f o 咖”，则j s p 页面中的( m m l ：f o m ) 元素的 n 锄e 属性也应该是“l 0 西n f 0 加”。 1 8 客户服务调查记录的查询； 5 系统用户管理功能 系统用户信息的录入，包括用户名和密码； 系统用户信息的修改： 系统用户信息的删除； 5 2 功能模块划分 从功能描述的内容可以看出，本系统可以实现五个完整的功能。我们根据这些功能， 设计出系统的功能模块，如图5 1 所示。 图5 1 客户售后服务管理系统功能模块示意图 在功能模块示意图的树状结构中，每一个叶结点都是一个最小的功能模块。每一个 功能模块都需要针对不同的表完成相应的数据库操作，即添加记录、修改记录、删除记 录、以及查询显示记录。 客户售后服务管理系统的功能模块之间的关系如图5 2 所示 薹 工工客 作作 户 服 耋 提供数据任提供数据任 提供数据 务 务 务 反 囊 分记 馈 动 配 录能 图5 - 2 客户售后服务管理系统的功能模块关系图 在本系统中，用户管理模块的功能比较简单，在系统初始化时，有一个默认的“系 统管理员”用户a d m i n ，由程序设计人员手动地添加到数据库中。a d m i n 用户可以创建 用户、修改用户信息、以及删除用户：普通用户则只能修改自己的用户名和密码。 2 2 5 3 系统流程分析 由于本系统面向五种不同的用户，所以有五个入口点供访问，即内部员工、内网用 户、个人用户、公司用户以及合作公司用户。不同的用户对应不同的程序流程，但在大 体功能划分上可以分成两部分。内部员工通过用户登录进入系统，负责处理客户售后服 务管理系统中的各种业务，其余四种用户可以通过网站( 内网或外网) 直接登录系统，提 交自己的问题，在通过合法性检验后，得到自己唯一的服务i d ，以及预约领取机器时 间。得到服务i d 后，客户还可以通过此d 随时查询自己问题的被服务状态。 内部员工进入本系统的流程分析如图5 3 所示： 图5 - 3 内部员工进入系统流程分析 客户进入本系统的流程分析如图5 4 所示： 图5 - 4 客户进入系统流程分析 5 4 系统开发工具和运行环境 w e b 服务器：m mw 曲s p h e r e 数据库：i b m d b 2 开发语言：j a v a 、j s p 开发工具：m m w s a d 5 5 系统的s t m t s c o n j j g x i n i 配置文件和w e b x l n l 配置文件 5 。5 1s t r u t s c o n 丘晷x m i 该文件是s t n l t s 核心文件，s t n l t s c o n f i g x m l 集中了所有页面的导航定义。对于大型 的w e b 项目，通过此配置文件即可迅速把握其脉络，这不管是对于前期的开发，还是 后期的维护或升级都是大有裨益的。 1 配置f 0 h n b e a n s 元素， 元素用来配置视图中使用的a c t i o n f o 曲类。每个 元素用 于设置一个a c t i o n f o 蛐b e a n 的各个属性。需要设置的最主要的属性是n a m e 和t y p e 。 2 4 n 锄e 属性是该a c t i o n f o 皿b e a i l 的唯一标识符，s t m t s 框架用该标识符来引用这个b e a i l 。 t y p e 属性用于指定a c t i o n f o 加类的完整类名。配置代码如下： 2 配置百o b a l e x c e p t i o n s 元素 它用来将系统异常统一转到出错页面。比如s e s s i o n 超时 3 配置a c t i o n m a p p i n 笋元素 a c t i 衄m 印p i n g s 元素包含一系列的零个或多个s 仃u t s 应用程序的a c t i o n 元素。控制 器将通过请求中的u r l 路径与a c t i o n 元素中的p a t h 属性进行匹配来选择一个特定的映 射。代码如下： 4 配置m e s s a g e - r e s o u r c e s 元素 它指定了包含应用程序的本地化消息资源绑定的特性。每一个s t n l t s 配置文件可以 定义一个或多个消息资源绑定。 中进一步采取了以下策略来保证j s p 页面的整洁清爽并利于维护。 1 页面布局的一致性 系统中所有的j s p 页面都由头部( h e a d ) 、导航( n a v i ) 、主页面( c o n t e n t ) 和尾部( f b o t ) 构成，页面的头部、导航和尾部形成了整个页面的基本风格，能够给客户以整洁、美观 的视觉享受。 由于本系统的用户为跨国r r 公司，所以有一套成熟、完善的管理标准。其中针对 该公司使用的各种w e b 软件系统，制订了非常详尽的内部网( w 3 ) 标准和姗e m e t 标准 ( m v w ) 。本系统的所有页面的头部、尾部都是严格遵照此标准，使用该标准提供的已经 定义好的链接和样式生成。这样就避免了对这些代码片断的重复拷贝，也是对j s p 设 计中复合视图模式的利用，这样不但可以保证系统中整个w e b 页面的布局一致，而且 也大大提高了页面的可维护性。 2 _ j a v a b e a l l 的使用 j a v a b e 孤是j s p 页面中封装数据的最佳手段，在系统中被大量使用，在a c t i o n 组 件处理完请求之后，它将j s p 页面要使用的a 吐i o n f o 肋或j a v a b e a n 对象放置在 h t t p s e r v l e t r e q u e s t 的a t t r i b u t e 变量中，然后在j s p 页面中就可以利用 、 等标准标签来操作该变量，避免了在页面中直接嵌入j a v a 代码来调用 j a v a b e a i l 属性存取的g e t t e r s e t t c r 方法，是减少j s p 页面中j a v a 代码片断的有力手 段，显著提高了j s p