系统架构设计系统架构设计说明书设计说明书 说明书 版本号：版本号：V0.1 0.1 2010年7月 1. 目的 本说明书的编写目的是描述系统的架构设计方案，包括系统的软件总体架构设计及使用的框架说明，以及基于该架构的开发流程，并作为指导开发人员、测试人员进行系统开发及测试的依据。 2. 系统架构设计 整个软件架构方案采用分层、分布式的部署结构，明确地分离了表现层和业务逻辑，能够保证应用服务逻辑的一致性和稳定性、结构的开放性、功能的可扩展性和可维护性、开发的可并行性，同时采用一些开源的框架，兼顾了经济性。框架是一种特殊的软件，它为软件开发带来了高度的重用性，是无数软件开发人员的多年项目开发经验的总结。在一个优秀的框架上开发应用，而不是从零开始，可以大量缩短项目的开发周期、降低开发风险、增强应用系统的稳定性。 用户层 STB客户端 视频 WEB浏览器（IE） P4P视频传输服务 游戏 视频 CMS BOSS EPG DTO DTO WEB应用 服务器 DTO DTO 第三方 平 台 NMS网络监控服务 数据访问层 DAO Hibernate JDBC JDBC 系统总体架构图 系统总体架构如上图所示，按功能可以分为P4P视频传输服务、CDN视频分发服务、NMS网络监控服务、内容管理系统（CMS）、业务运行支持系统（BOSS）、电子节目单发布系统（EPG）；系统根据功能特点与业务需求采用C/S和B/S两种架构模式，其中，P4P视频传输服务采用XBT开源项目，XBT项目基于纯C++代码实现，可以运行于Linux和Windows平台，支持UPNP和NAT穿透；CDN视频分发基于FTP协议实现视频文件的分发传输；NMS网络监控服务采用OpenNMS开源项目，OpenNMS是基于开源协议开发的企业级网络管理系统，支持Linux和Windows平台。支持SNMP网络管理协议确保管理的扩展性，可以监控各个终端及服务器的故障及资源使用状况，并以图形化的方式展现出来；内容管理系统（CMS）、业务运行支持系统（BOSS）与电子节目单发布系统（EPG）采用基于WEB的B/S结构，技术架构采用J2EE标准的多层架构，基于并且集成Ext、Struts、Spring、Hibernate开源框架，以后称为WEB子系统。 3. WEB子系统架构设计 操作系统 RedHat Linux 数据库 Oracle JBOSS Server 表 Struts+Ext 示 JSP 层 DTO 业 务 层 DTO 数据访问层 DAO JDBC Web服务器 Apache Server 用户层 ActionForm Action DTO DTO iBatis JDBC 从架构图中可以看出系统分为四层： • • • • 用户层：浏览器 表示层：借助Struts及Ext实现 业务层：借助Spring进行业务组件的组装关联。 数据持久层：借助Hibernate实现 为什么采用这样的四层架构？ • 通过成熟的开源产品实现各层，同自己编写代码实现，相比之下能缩短开发周期，且架构所用到的开源产品均有很广泛的用户群，经受过实践的考验，质量和性能更有保障。 • • 层与层之间松散耦合，增加代码重用率。 各层分工明确，这样也利于团队的明确分工。 系统的总体架构从结构上分为用户层、表示层、业务层、数据访问层以及在层间传递数据的数据传输对象。下面针对各层加以描述。 1)．用户层 用户层作为客户端程序，用来与用户交互，并把来自系统的信息显示给用户。系统的用户层采用的是IE浏览器作为交互方式。 2）．表示层 表示层主要控制页面外观，产生页面逻辑以及对用户输入的数据进行合法性验证。系统中主要包括基于EXT框架的JavaScript脚本及基于Struts框架的JSP、Action、ActionForm。其中JavaScript脚本可以增强用户体验，JSP负责视图的功能，由HTML、 Java程序片断和JSP标签构成；ActionForm Bean用于在视图组件和控制器组件之间传递HTML表单数据，通常每个HTML表单对应一个ActionForm Bean，HTML表单中的字段和ActionForm Bean中的属性一一对应。ActionForm的validate()方法用于对用户输入的数据进行合法性验证；Action负责单个事件的流程控制。 3）．业务层 业务层处理应用的核心业务逻辑。业务逻辑对象BLO(Business Logic Object) 把业务规则、约束、活动和数据结合在一起，Spring负责对这些业务对象的管理。 4）．数据访问层 数据访问对象(Data Access Object) 把底层的数据访问操作和上层的商务逻辑分开。 5）．数据传输对象（Data Transfer Object） 数据传输对象通常作为各业务实体的JAVABEAN对象，负责层与层之间数据的传输。 目录结构及包设计 J2EE规范定义了Web应用程序的类和文件存放的目录结构。该层次结构由三个层次构成。第一层是上下文，它是一个目录或者是多个目录，用来查找与客户请求关联的Web应用程序。在上下文中存在一个/WEB-INF目录，该目录标记着另一个层次，它包含一个子目录，帮助组织类文件和压缩的包文件。/WEB-INF还包含一个映射所有文档并定义整个应用程序特性的文档。最后一层直接位于上下文中，包含所有客户端可见的文件，包括用户界面文件、图形和音频文件。 表1-1 系统目录结构表 目录名 说明 /root 应用上下文根目录 /css Css样式表文件目录 /img 图片文件目录 /js JavaScript文件目录 /cms jsp文件目录 /web-inf /conf 配置文件目录 /lib 压缩的java类文件，组件的JAR文件 /classes 本系统的java类文件 /tld Tag库文件 web.xml 部署描述符文件 classes目录下的系统的java文件的包结构说明见表1-2。 表1-2 CMS系统包结构说明表 包名 com.gecai.base com.gecai.base.web com.gecai.base.web.action com.gecai.base.web.form com.gecai.base. service com.gecai.base. service.impl com.gecai.base.hibernate com.gecai.base.hibernate.pojo com.gecai.base.common com.gecai.cms com.gecai.cms.web com.gecai.cms.web.action com.gecai.cms.web.form 作用说明 基础架构 基础架构的表示层 基础架构的表示层的Action类 基础架构的表示层的Form类 基础架构的业务层 基础架构的业务层的实现类 基础架构的数据访问层 基础架构的数据访问层的数据对象类 基础架构的共同类包 CMS子系统 CMS子系统的表示层 CMS子系统的表示层的Action类 CMS子系统的表示层的Form类 com.gecai.cms. service com.gecai.cms. service.impl com.gecai.cms.hibernate com.gecai.cms.hibernate.pojo CMS子系统的业务层 CMS子系统的业务层的实现类 CMS子系统的数据访问层 CMS子系统的数据访问层的数据对象类 4. WEB子系统架构总体功能设计 4.1 Struts框架 Struts是一个实现了MVC模式的框架，对Model、View和Controller都提供了对应的实现组件。可分为1.x和2.x两大版本，如下图所示： 1．控制器（Controller） 控制器的作用是从客户端接受请求，并且选择执行相应的业务逻辑，然后把响应结果送回到客户端。在Struts1中Controller功能由图中ActionServlet和ActionMapping对象构成：核心是一个Servlet类型的对象ActionServlet，它用来接受客户端的请求。ActionServlet包括一组基于配置的ActionMapping对象，每个ActionMapping对象实现了一个请求到一个具体的Action处理器对象之间的映射；在Struts2中Controller为基于事务拦截的拦截器，针对每次客户端请求Action进行拦截分发。 2．模型（Model） MVC系统中的Model部分从概念上可以分为两类--系统的内部状态，和改变系统状态的动作。Struts1为Model部分提供了Action和ActionForm对象：所有的Action处Action处理器对象封装了具体的理器对象都是开发者从Struts的Action类派生的子类。 Controller Model Action Struts配置文件 处理逻辑，调用业务逻辑模块，并且把响应提交到合适的View组件以产生响应。Struts提供的ActionForm组件对象，它可以通过定义属性描述客户端表单数据。开发者可以从它派生子类对象，利用它并结合Struts提供的自定义标记库，可以实现对客户端的表单数据的良好封装和支持，Action处理器对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过ActionForm组件对象实现了对View和Model之间交互的支持；Struts2的Action为ActionSupport基类的子类，由于对于每一个Action请求生成一个实例对象，不存在线程安全问题。 3．视图（View） Struts应用中的View部分是通过JSP技术实现的。Struts提供了自定义的标记库可以使用，通过这些自定义标记可以非常好地和系统的Model部分交互，通过使用这些自定义标记创建的JSP表单，可以实现和Model部分中的ActionForm的映射，完成对用户数据的封装，同时这些自定义标记还提供了像模板定制等多种显示功能。 4.2 Spring框架 Spring是一个轻量级的实现了控制反转(IoC)和面向切面(AOP)的容器框架，其组件包括： 1．Core包 Core包是框架的最基础部分，它提供依赖注入（Dependency Injection）特性来管理Bean容器功能。 2．Context包 Context包提供了框架的资源访问方式，如JNDI、资源装载等的接口。 3．DAO包 DAO包提供了JDBC的抽象层，它可消除冗长的JDBC编码和解析数据库厂商的特有代码。该包也提供了实现编程性和声明性事务管理的方法。 4．ORM包 ORM包为流行的关系－对象映射APIs提供了集成层，包括JDO，Hibernate和iBatis。 5．AOP包 AOP包提供与AOP联盟兼容的面向方面编程实现，允许用户定义，如方法拦截器和切点，来从逻辑上把应该被分离的功能实现代码解耦。 6．Web包 Web包提供了基本的面向Web的特性。如MVC以及与其他Web框架的结合。 Spring提供了一致的事务管理抽象。这个抽象是Spring最重要的抽象之一， 它有如下的优点： • 为不同的事务API提供一致的编程模型，如JTA、JDBC、Hibernate、iBatis数据库层 和JDO。 • • • 提供比大多数事务API更简单的，易于使用的编程式事务管理API。 整合Spring数据访问抽象。 支持Spring声明式事务管理。 Spring使应用开发者能够使用在任何环境下使用一致的编程模型，只写一次代码，就可以实现不同环境下的事务管理。Spring同时提供声明式和编程式事务管理。其中声明式事务管理仅通过一些配置就使得事务管理从业务逻辑分离出来，极大地减轻了开发人员的负担。 4.3 Hibernate框架 Hibernate是一个实现了以ORM模式实现了持久层的框架，由于数据库的读写是一个很耗费时间和资源的操作，当大量用户同时直接访问数据库的时候，效率将非常低，如果将数据持久化就不需要每次从数据库读取数据，直接在内存中对数据进行操作，这样就节约了数据库资源，而且加快了系统的反映速度。 Hibernate 提供的接口可以分为以下几类： （1） 提供访问数据库的操作的接口，包括session、Transaction、Query接口； （2） 用于配置Hibernate的接口，Configuration； （3） 间接接口，使应用程序接受Hibernate内部发生的事件，并作出相关的回应，包括：Interceptor、Lifecycle、Validatable； （4） 用于扩展Hibernate功能的接口，如UserType、CompositeUserType、IdentifierGenerator接口。 Hibernate内部还封装了JDBC、JTA（Java Transaction API）和JNDI（Java Naming And Directory Interface）。其中，JDBC提供底层的数据访问操作，只要用户提供了相应的JDBC驱动程序，Hibernate可以访问任何一个数据库系统。JTA和JNDI使Hibernate能够和J2EE应用服务器集成。 4.4 ExtJS框架 ExtJS是一个JavaScript框架，包括丰富的JS函数库，用于在客户端创建丰富多彩的Web应用程序界面，增强用户体验及界面友好性。ExtJS由一系列的类库组成，包括如下几个部分： 底层API（core）：底层API中提供了对DOM操作、查询的封装、事件处理等基础功能，其他控件也是建立在这些底层API的基础上的。 控件（widgets）：控件是指可以直接在页面创建的可视化组件，如面板、选项板、表格、树、窗口、菜单、工具栏、按钮等，在系统中可以直接通过应用这些控件来增强界面的友好及交互性。 实用工具（utils）：Ext提供了很多实用的工具，通过它们可以实现数据内容格式化、JSON数据解析、AJAX调用、Cookie管理、CSS管理等功能。 同时，Ext也是一个Ajax框架，提供了一套通过AJAX方式与服务器异步交互的机制，即不通过页面刷新就可以访问服务器的程序进行数据读取与保存。ExtJS与服务器端的数据交互可以通过XML或JSON对象格式。由于JSON对象格式比XML格式更易于解析和理解，本系统前端与服务器端进行数据交互的方式采用JSON对象。 4.5 缓存机制 缓存是介于应用程序和物理数据源之间的数据内存，其作用是为了降低应用程序对物理数据源访问的频次，从而提高了应用的运行性能。缓存内的数据是对物理数据源中的数据的复制，应用程序在运行时从缓存读写数据，在特定的时刻或事件会同步缓存和物理数据源的数据。 Hibernate提供了两级缓存架构，第一级缓存是Session缓存；该级缓存缺省被Hibernate启用，并且是基于事务级别的缓存。第二级缓存是SessionFactory缓存，该级缓存对Hibernate来说是可选的且可通过缓存插件来进行配置，并且是基于应用级别的缓存，也就是说它被该应用范围内的所有事务所共享。由于Hibernate的二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。为此，Hibernate提供了针对条件查询的Query缓存，该缓存可以把某个或多个Query查询放入到二级缓存中。 当然，二级缓存的使用也需要一些前提条件，并且带来了一些限制。首先要求Hibernate程序对数据库有独占的写访问权，其他的进程更新了数据库，Hibernate是不可能知道的。所有操作数据库必需直接通过hibernate，如果调用存储过程，或者使用jdbc更新数据库，Hibernate也是不知道的，hibernate的大批量更新和删除是不更新二级缓存的，这样就限制了大批量更新和删除的数据的使用。 针对该系统前期系统用户量不大、并发要求不高的情况，只采用一级缓存。 4.6 数据批量处理 数据批量处理是指在一个事务中处理大量数据，一般说来，应该尽可能避免在应用程序中进行批量操作，而应该在数据库中直接进行批量操作，但同时带来了数据库的可移植性差，所以针对小批量的数据更新（100条以内），可以在应用层进行批量操作，操作方式主要有：（1）通过Session来进行批量操作。（2）通过StatelessSession来进行批量操作。（3）通过HQL来进行批量操作。（4）直接通过JDBC API来进行批量操作。 为了开发方便，我们选用Session来进行批量操作，Session的save()以及update()方法都会把处理的对象存放在自己的缓存中。如果通过一个Session对象来处理大量持久化对象，应该及时从缓存中清空已经处理完毕并且不会再访问的对象。具体的做法是在处理完一个对象或小批量对象后，立刻调用flush()方法清理缓存，然后再调用clear()方法清空缓存。并且需进行如下设置：（1）需要在Hibernate的配置文件中设置JDBC单次批量处理的数目，合理的取值通常为10到50之间，本系统采用hibernate.jdbc.batch_size=20，并应保证每次向数据库发送的批量SQL语句数目与这个batch_size属性一致。（2）如果对象采用\"identity\"标识符生成器，则Hibernate无法在JDBC层进行批量插入操作。（3）批量操作时关闭二级缓存。 4.7 加锁机制 加锁对于数据库来说是保障并发和数据一致性的重要手段，Hibernate作为对数据库实现持久化的一个框架，同样也有自己的加锁机制，Hibernate的加锁机制有悲观锁和乐观锁两种机制。悲观锁(Pessimistic Locking)假定任何时刻存取数据时，都可能有另一个事务也正在存取同一笔数据，为了保持数据被操作的一致性，于是对数据采取了锁定状态，Hibernate的加锁依靠数据库提供的锁机制来实现；乐观锁（Optimistic Locking）认为数据库的存取很少发生同时存取的问题，因而不对数据锁定。为了维护正确的数据，乐观锁是使用应用程序上的逻辑来实现版本控制的。Hibernate中通过检查版本号来判断数据是否已经被其他人所改动，在数据库中加入一个version字段记录，在读取数据时连同版本号一同读取，并在更新数据时比较版本号与数据库中的版本号，如果等于数据库中的版本号则予以更新，并递增版本号，如果小于数据库中的版本号就抛出异常。 悲观锁从根本上保证了数据的一致性，但因为等待解锁带来了性能及数据库表死锁的问题；针对本系统数据库表的更新操作并发量不大的特点，适合采取悲观锁，并采取防死锁机制。 4.8 防死锁机制 在数据库系统中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁，从而出现死锁等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法。预防死锁通常有两种方法：一次封锁法，一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。一次封锁法虽然可以有效地防止死锁的发生，但由于扩大了加锁的范围，降低了系统的并发度；顺序封锁法，顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序执行封锁。 在本系统中将定义一个数据库表的访问顺序，并要求所有的事务都按照这个顺序访问操作数据库。 4.9 表单验证 对Web应用来说，由于用户的行为是无法预测的，在表单数据在传递给业务类之前，必须保证数据的合法性及有效性，而表单验证是保证数据合法性及有效性的重要手段。对于基于SSH框架的表单验证一般有两种方式：基于JavaScript的表单验证（前端验证）及基于Struts的表单验证（后端验证）。 前端验证：前端验证： 可以针对基本类型（汉字、英文、整型、数字、日期、邮编）的有效性及合法性开发出一些共同JavaScript函数，以备整个系统统一调用。 后端验证：后端验证： 主要采用基于Struts的表单验证，通过ActionForm的validate函数进行验证。 由于前端验证不需要提交服务器，直接在客户端完成，从而减少了服务器的压力，所以我们优先采用前端验证。 4.10 异常处理 异常处理的目的是为了让用户看到异常的详细信息，定位异常发生的原因，让开发人员对预期的异常进行处理，进一步提高系统的健壮性。 Java语言拥有一套自己的异常处理机制，在Java的异常体系结构中，异常被分为两类：一类是基于java.lang.Exception 的异常，被称为检查异常，这类异常必须在程序中予以扑获；另一类是基于java.lang.RuntimeException 的异常，被称为运行异常，这类异常不必在程序中扑捉，而且用户对这类异常一般无法恢复，但通过业务处逻辑的判断理可以让程序避免这类异常的出现。 针对J2EE应用的多层架构，数据访问层和业务层可以根据需要向上层抛出相应的Exception，而这些Exception须在Action类中捕捉，并向页面返回一个合适的信息，具体展现根据情况来定，针对普通页面的异常，一般显示错误页面；Ajax发生的异常，返回一个包含错误信息的JSON对象，以Ajax方式显示。系统首先定义一个异常基类BaseException，然后扩展定义BaseDAOException作为数据访问层的异常，扩展定义BaseBusinessException作为业务访问层的异常，而Action层的异常不做处理，通过Struts框架统一处理，并把表示层的异常统一转向异常页面，并提示异常信息。 系统都需要用日志文件来记录系统的运行，以便于跟踪和记录系统的运行情况。系统发生的异常理所当然的需要记录在日志系统中，并且仅在最初产生异常的位置记录，在以后抛出并捕获该异常的位置则不再记录。 4.11 日志处理 规范合理的日志记录能让开发人员和维护人员事半功倍，在记录日志时还应该考虑不同的角色对日志内容可能会有 不同的需求。比如，软件正常情况下提供给用户的日志应该简洁明了，调试时提供给程序员的日志应该详细明确。 LOG4J作为一个开源的日志管理组件，提供了强大的日志管理功能，可以把日志输出到控制台、文件或其他地方，支持包括Fatal、Error、Warn、Info、Debug多级日志输入。并可以通过配置来控制日志的格式、输出级别。 本系统要求在每个函数的开始、结束位置、异常的初次抛出位置均要求输出到日志记录文件，并把用户的系统操作记录存入到数据库日志表。 5. 共同组件 5.1 分页组件 数据列表是页面的一种常见页面表现形式，而分页功能又是列表的一个不可缺少的功能，分页组件主要为各种形式的数据列表提供一个共同的分页功能。技术上可以分两种实现方法：一是查询出所有的符合条件的数据记录，在JSP页面进行分页计算。这种方法在数据量少的情况很方便，而且不影响效果，但对于大数据量的情况，将严重影响性能；二是首先查询出总的符合条件的数据记录数，然后每次只查询出一页的数据记录，这种方法对于大数据量的情况性能很好。本系统将采用第二种方法。由于Hibernate提供了对数据库定点定量查询的方法，DAO 层的数据分页查询可以基于Hibernate实现，也可以基于特定数据库的定点定量查询SQL实现。页面表现可以基于Ajax技术，实现无刷新效果，组件调用接口要求简洁明了。 5.2 树形组件 树形结构一般用于组织机构等具有层次结构的数据，也是页面常见的表现形式，树形组件为各种形式的层次结构数据提供一个共同的分页功能。技术上可以分两种实现方法：一是查询出所有的层次节点的符合条件的数据记录，在JSP页面进行分层显示。二是只查询显示层次节点的数据，展开时查询该节点的子节点的数据，这种方法适合大数据量的情况，但用户交互效果不好。考虑到层次结构数据一般数据量不大的特点，我们采用第一种方法。针对大数据量的情况可以采用数据列表的形式来表示。页面表现可以基于Ajax技术，实现无刷新效果，组件调用接口要求简洁明了。 5.3 DAO基类（BaseDAO） 由于系统架构的DAO层采用Hibernate框架，所以BaseDAO基类应继承Hibernate的HibernateDaoSupport类，并实现数据对象的增删改查数据库操作，具体可以参照Hibernate文档。 5.3 Service基类（BaseManager） 该类作为业务层Service类的基类，所有业务层Service类必须继承该类。该类实现接口IBaseManager(所有接口的名称定义为I+Service类名)，并封装BaseDAO类及业务类的共同操作方法。 5.3 Action基类(BaseAction) 针对Struts1，BaseAction基类继承Struts1的DispatchAction类，并实现Action类的共同方法，所有表现层Action类继承BaseAction；BaseForm类继承ActionForm类，并通过实现Validate()方法来进行数据验证。 针对Struts2，BaseAction基类继承Struts2的ActionSuport类，封装BaseForm类并实现Action类的共同方法，所有表现层Action类继承BaseAction，并封装相应的Form类。Struts提供编程式和声明式，由于编程式灵活，系统统一采用编程式验证，开发人员需要实现Action的Validate() 方法来进行数据验证。 6. WEB子系统基于架构的开发流程 6.1 编写Service类 1. 定义Service接口类 public interface IExampleManager { public void getCode() throws BaseBusinessException; } } 2. 实现Service类 public class ExampleManager extends BaseManager implements IExampleManager{ /** * 取得Code */ public void getCode() throws BaseBusinessException { try{ TbCodeId cid = new TbCodeId(\"1\",\"1\"); dao.getObject(TbCode.class,1); }catch(BaseDAOException ex){ log.error(ex.getMessage(), ex); throw new BaseBusinessException(ex.getMessage()); } } 注意： Service类必须继承BaseManager基类 方法对BaseDAOException异常扑捉，并根据业务需求进行处理，并抛出 BaseBusinessException。 访问数据库操作调用基类的DAO属性进行操作，不需再单独定义DAO类。 为了减少Spring中注入类的数量，以加快启动时间，系统对Service类进行IOC管理，而对Action类不进行IOC管理，所以，在进行数据库的更新操作时，须在Service类的一个方法中完成一个事务的所有操作，而不应该在Action中完成一个事务的操作。 3.在applicationContext-Cms.xml中配置Service类，纳入Spring容器管理
6.2 单体测试Service类 在test包内测试类，命名为Service类名+Test。 public class HelloTest {{ ApplicationContext cxt; @Before public void setUp() throws Exception { String[] xmllocations={\"/WebRoot/WEB-INF/applicationContext-DataSource. xml\",\"/WebRoot/WEB-INF/applicationContext-Hibernate.xml\", \"/WebRoot/WEB-INF/applicationContext-Spring.xml\",\"/WebRoot /WEB-INF/applicationContext-Cms.xml\"}; cxt = new FileSystemXmlApplicationContext(xmllocations); } @Test public void testService() { try{ IExampleManager manager = (IExampleManager)cxt.getBean(\"CodeManager\"); manager.getDepartment(); }catch(Exception e){ e.printStackTrace(); } } 注：CodeManager为在ApplicationContext-Cms.xml文件中定义的BeanID 6.2 编写Action类 1. 编写Action类 public class ExampleAction extends BaseAction { public String execute() throws Exception { //IOC调用业务类 IExampleManager exaManager=(IExampleManager) getBean(\"CodeManager\"); exaManager.getDepartment(); //设置消息 setMessage(getText(getMessage())); return SUCCESS; } 注：1.类必须继承BaseAction基类 2.CodeManager为在ApplicationContext-Cms.xml文件中定义的BeanID 2.配置Action 建立一个自己专用的XML文件，以后每人在自己的ＸＭＬ文件中管理自己的Action类，并在Struts.xml文件中添加该配置文件：
并在example.xml文件中添加该Action的配置： /example.jsp 注：为了避免出现大量的Action类，本系统开发时，Action类采用动态方法调用，类名及方法名的命名规则参见类定义说明书。 其中：配置格式如: /example.jsp 页面调用格式： Action=\"Action实例名!方法名.action\" 6.3 单体测试Action类 @Test public void testExecute() { try{ ExampleAction ea = new ExampleAction(); //设置测试用session变量 ea.setSessionObject(\"name1\", \"value1\"); ----1 //设置Request变量 MockHttpServletRequest request = new MockHttpServletRequest(); request.setParameter(\"name2\", \"value2\"); -----2 ea.setRequest(request); //执行 ea.execute(); }catch(Exception ex){ ex.printStackTrace(); } 注：1. 若Action中有需要Session变量，则需要往Session中设置该值 2. 若Action中有需要Request变量，则需要往Request中设置该值 6.5 编写页面 在JSP页面中，可以优先使用Struts2标签、EXTTLD标签及JSP标签。原则上讲，针对页面刷新时用的元素应该用Struts2标签；针对页面局部刷新或不刷新时用的元素应该采用EXTTLD标签。 6.6 页面测试 在完成上述步骤后，就可以根据业务逻辑，设置页面的转移，然后进行页面联动测试。