Struts的体系结构

（Struts Framework Architecture）
关键字
Struts,Framework,Architecture,Componennt,MVC
预备知识
在开始学习Struts以前，以下的知识点，需要有所了解： 模型-视图-控制的软件构架模式，JSP/Servlet的web层应用，J2EE体系结构。如果对客户标签类（Customer TagLib）有所了解也许更容易理解Struts本身的TagLib。

概述
本文主要从概念上讲解什么是struts framework，它的框架结构，组件结构，以及简单的配置讲解。对于其应用请参考后面的“struts安装及应用”和“struts实用案例分析”。
文章的包括了如下四大部分：
一、 Framework的概念和体系简介 （Framework Conception and Architecture）
二、 Struts的概念和体系结构（Struts Conception and Architecture）
三、 Struts的工作原理和组件（Struts Componennts）
四、 Struts配置文件简介（Struts Deployment Description）

一、 Framework概念
一直以来我们都说struts是一个web framework。那么让我么先来看看什么是Framework。（我想用“框架”一词来翻译framework，可是后来越来越发现不太理想和完备，所以就直接用Framework一词）
Framework概念并不是很新了，伴随着软件开发的发展，在多层的软件开发项目中，可重用、易扩展的，而且是经过良好测试的软件组件，越来越为人们所青睐。这意味着人们可以将充裕的时间用来分析、构建业务逻辑的应用上，而非繁杂的代码工程。于是人们将相同类型问题的解决途径进行抽象，抽取成一个应用框架。这也就是我们所说的Framework。
Framework的体系提供了一套明确机制，从而让开发人员很容易的扩展和控制整个framework开发上的结构。 通常，framework的结构中都有一个“命令和控制”组件（"command and control" component）——Framework Factory and Manager。

图片（2）：Framework体系


通过基于请求响应（Request-Response）模式的应用framework，基本上有如下几个表现逻辑结构组成。
（1）控制器（Controller）——控制整个framework中各个组件的协调工作。
（2）业务逻辑层（Business Logic）——这是framework所希望解决问题的关键。当然对framwork本身来说，这里仅仅只是概念和几个提够服务的基础组件，真正的实现与客户的业务逻辑接轨，还需要开发人员在framework上再次扩展。
（3）数据逻辑层（Data Logic）——绝大应用系统都需要涉及到数据交互，这一层次主要包括了数据逻辑和数据访问接口。对于数据逻辑来说，如果你了解数据建模（Data Modeling）可能就很容易理解。

下面就进入我们的正题——Struts的结构

二、 Struts的概念和体系结构
Struts有一组相互协作的类（组件）、Serlvet以及jsp tag lib组成。基于struts构架的web应用程序基本上符合JSP Model2的设计标准，可以说是MVC设计模式的一种变化类型。根据上面对framework的描述，我们很容易理解为什么说Struts是一个web framwork，而不仅仅是一些标记库的组合。但 Struts 也包含了丰富的标记库和独立于该框架工作的实用程序类。
Struts有其自己的控制器（Controller），同时整合了其他的一些技术去实现模型层（Model）和视图层（View）。在模型层，Struts可以很容易的与数据访问技术相结合，包括EJB,JDBC和Object Relation Bridge。在视图层，Struts能够与JSP, Velocity Templates,XSL等等这些表示层组件想结合。

2.1 Struts的与Web App的关系

既然struts叫做web framework，那么其肯定主要基于web层的应用系统开发。按照J2EE Architecture的标准，struts应当和jsp/servlet一样，存在于web container一层。如图片(3)所显示
图片（3）： Struts与WebApp的关系

2.2 Struts的体系结构
我们说struts framework是MVC 模式的体现，下面我们就从分别从模型、视图、控制来看看struts的体系结构（Architecture）。图片（4）显示了struts framework的体系结构响应客户请求时候，各个部分工作的原理。
图片（4）：Struts体系结构

2.2.1从视图角度（View）
主要由JSP建立，struts自身包含了一组可扩展的自定义标签库（TagLib），可以简化创建用户界面的过程。目前包括：Bean Tags，HTML Tags，Logic Tags，Nested Tags，Template Tags　这几个Taglib。有关它们的详细资料请参考struts用户手册
2.2.2从模型角度（Model）
模型主要是表示一个系统的状态（有时候，改变系统状态的业务逻辑操作也也划分到模型中）。在Struts中，系统的状态主要有ActiomForm Bean体现，一般情况下，这些状态是非持久性的。如果需要将这些状态转化为持久性数据存储，Struts本身也提供了Utitle包，可以方便的与数据库操作
2.2.3 从控制器角度（Controller）
在Struts framework中， Controller主要是ActionServlet，但是对于业务逻辑的操作则主要由Action、ActionMapping、ActionForward这几个组件协调完成（也许这几个组件，应该划分到模型中的业务逻辑一块）。其中，Action扮演了真正的业务逻辑的实现者，而ActionMapping和ActionForward则指定了不同业务逻辑或流程的运行方向。

2.3 Struts的基本组件包
整个struts大约有15包，近200个类所组成，而且数量还在不断的扩展。在此我们不能一一介绍，只能列举几个主要的简要的介绍一下。下表说明了目前struts api中基本的几个组件包，包括action,actions,config,util,taglib,validator。图片（5）则显现了这几个组件包之间的关系。其中action是整个struts framework的核心
org.apache.struts.action
基本上，控制整个struts framework的运行的核心类、组件都在这个包中，比如我们上面提到的控制器ActionServlet。已经Action,ActionForm,ActionMapping等等。struts1.1比1.0多了 DynaActionForm 类。增加了动态扩展生成FormBean功能
org.apache.struts.actions
这个包是主要作用是提供客户的http请求和业务逻辑处理之间的特定适配器转换功能，而1.0版本中的部分动态增删FromBean的类，也在struts1.1中被Action包的DynaActionForm组件所取代
org.apache.struts.config
提供对配置文件struts-config.xml元素的映射。这也是sturts1.1中新增的功能
org.apache.struts.util
Strtuts为了更好支持web application的应用，体统了一个些常用服务的支持，比如Connection Pool和Message Source。详细信息请参考http://jakarta.apache.org/struts/api/org/apache/struts/util/package-summary.html
org.apache.struts.taglib
这不是一个包，而是是一个客户标签类的集合。下面包括Bean Tags，HTML Tags，Logic Tags，Nested Tags，Template Tags这几个用于构建用户界面的标签类。
org.apache.struts.validator
Struts1.1 framework中增加了validator framework，用于动态的配置from表单的验证。详细信息请参阅 http://home.earthlink.net/~dwinterfeldt/





三、 Struts framework的工作原理和组件
对于Struts 如何控制、处理客户请求，让我们通过对struts的四个核心组件介绍来具体说明。这几个组件就是：ActionServlet。Action Classes，Action Mapping（此处包括ActionForward），ActionFrom Bean。
3.1 Struts ActionServlet
ActionServlet继承自javax.servlet.http.HttpServlet类，其在Struts framework中扮演的角色失控制器，参看上面的“Struts体系图”。控制器ActionServlet主要负责将HTTP的客户请求信息组装后，根据配置文件的指定描述，转发到适当的处理器。（在Struts1.1中新增了org.apache.struts.action.Action.RequestProcessor类，将处理请求的功能从控制器功能中分离。
按照Servelt的标准，所有得Servlet必须在web配置文件（web.xml）声明。同样，ActoinServlet必须在Web Application配置文件（web.xml）中描述，有关配置信息，后面将会介绍。

当用户向服务器端提交请求的时候，实际上信息是首先发送到控制器ActionServlet，一旦控制器获得了请求，其就会将请求信息传交给一些辅助类（help classes）处理。这些辅助类知道如何去处理与请求信息所对应的业务操作。在Struts中，这个辅助类就是org.apache.struts.action.Action。通常开发者需要自己继承Aciton类，从而实现自己的Action实例。

3.2 Struts Action Classes
一个Action 类的角色，就像客户请求动作和业务逻辑处理之间的一个适配器（Adaptor），其功能就是将请求与业务逻辑分开。这样的分离，使得客户请求和Action类之间可以有多个点对点的映射。而且Action类通常还提供了其它的辅助功能，比如：认证（authorization）、日志（logging）和数据验证（validation）。
Action最为常用的是execute（）方法。（注意，以前的perform方法在struts1.1中已经不再支持），还有一个execute（）方法，请参考apidoc，在此不在说明。
当Controller收到客户的请求的时候，在将请求转移到一个Action实例时，如果这个实例不存在，控制器会首先创建，然后会调用这个Action实例的execute（）方法。Struts Framework为应用系统中的每一个Action类只创建一个实例。因为所有的用户都使用这一个实例，所以你必须确定你的Action 类运行在一个多线程的环境中。下图显示了一个execute（）方法如何被访问：

图片（6）： Action实例的execute()方法

注意，客户自己继承的Action子类，必须重写execute（）方法，因为Action类在默认情况下是返回null的。


3.3 Struts Action Mapping
上面讲到了一个客户请求是如何被控制器转发和处理的，但是，控制器如何知道什么样的信息转发到什么样的Action类呢？这就需要一些与动作和请求信息相对应的映射配置说明。在struts 中，这些配置映射信息是存储在特定的XML文件（比如struts-config.xml）。
这些配置信息在系统启动的时候被读入内存，供struts framework在运行期间使用。在内存中，每一个<action>元素都与org.apache.struts.action.ActionMapping类的一个实例对应。下表就显示了一个登陆的配置映射。

上面的配置表示：当可以通过/logonAction.do（此处假设配置的控制器映射为*.do）提交请求信息的时候，控制器将信息委托com.test.LogonAction处理。调用LogonAction实例的execute()方法。同时将Mapping实例和所对应的LogonForm Bean信息传入。其中name=LogonForm，使用的form-bean元素所声明的ActionForm Bean。有关form-bean的申明如下显示。

元素<forward>则表示了当Action实例的execute()方法运行完毕或，控制器根据Mapping可将响应信息转到适当的地方。如上面现实，如果客户登陆成功，则调用welcome forward，将成功信息返回到/welcome.jsp页面。在你的execute()方法的结尾可以使用下面的实例代码而返回welcome forward。当然你的welcome forward必须在action元素属性中定义，正如上面所声明的那样。

在此稍稍说一下有关global-forwards的概念。其在配置文件中描述了整个应用系统可以使用的ActionForward，而不是仅仅是一个特定的Action。


3.4 Struts ActionForm Bean
在上面讲解ActionServlet，Action Classes和Action Mapping的时候，我们都提到了ActionForm Bean的概念。一个应用系统的消息转移（或者说状态转移）的非持久性数据存储，是由ActionForm Bean的负责保持的。
ActionForm的主要功能就是为Action的操作提供与客户表单相映射的数据（如果在客户指定的情况下，还包括对数据进行校验）。Action负责对系统数据状态的保持，而Action则负责根据业务逻辑的需要，对数据状态进行修改，在改变系统状态后，ActionForm则自动的回写新的数据状态并保持。
注意：在struts1.1中，ActionForm的校验功能，逐渐被剥离出来（当然依然可以使用）。使用了validator framework对整个应用系统的表单数据验证进行统一管理。相信信息请参考：http://home.earthlink.net/~dwinterfeldt
在ActionForm的使用中，Struts提倡使用到值对象（Value Object）。这样将客户或开发人员，对数据状态与对象状态能够更加清晰的理解和使用。
对于每一个客户请求，Struts framework在处理ActionForm的时候，一般需要经历如下几个步骤：
（１）检查Action的映射，确定Action中已经配置了对ActionForm的映射
（２）根据name属性，查找form bean的配置信息
（３）检查Action的formbean的使用范围，确定在此范围下，是否已经有此form bean的实例。
（４）假如当前范围下，已经存在了此form bean的实例，而是对当前请求来说，是同一种类型的话，那么就重用。
（５）否则，就重新构建一个form bean的实例
（６）form bean的reset()方法备调用
（７）调用对应的setter方法，对状态属性赋值
（８）如果validatede的属性北设置为true，那么就调用form bean的validate()方法。
注意：直接从ActionFrom类继承的reset()和validate()方法，并不能实现什么处理功能，所以有必要自己重新覆盖。
如果validate（）方法没有返回任何错误，控制器将ActionForm作为参数，传给Action实例的execute（）方法并执行。


有必要提一下有关org.apache.struts.action.DynaActionForm。这是struts1.1新增的特性。其继承自ActionForm，在struts早先版本中，我们必须人为的构造特定的ActionFrom子类，但是利用DynaActionForm，可以依据属性集而动态的创建from bean。有关其详细资料，请参考···


四、Struts的其他组件
Struts framework本身提供了很多可扩展的组件或sub framework，方便的开发人员在其构架上构建web层的应用系统。比如upload,collections ,logging等等。让我们来看看两个比较重要的组件：validationg framework和struts taglib。有关其他组件请参考Struts用户手册（http://jakarta.apache.org/struts/userGuide）。
在stuts1.0中有些很不错的概念和组件，比如benaUtils,Collections等等，后来被Jakarta Commons项目组吸收而独立处struts framework。但是struts依然需要依赖这些组件才能正常的工作。
4.1 Validation Framework for Struts
在struts1.1中，新增了validation framework。增加了对form数据提交的验证。将原本需要在ActionFrom Bean的validate（）进行的验证通过配置文件的描述进行验证。
有关其详细信息，请参考http://home.earthlink.net/~dwinterfeldt 。个人建议对于小型应用系统可以采用这种配置方式，但是对于应用系统中有大量web层表单应用的系统，并且业务需求变动比较大的，使用validation framework 可能会加重开发难度、系统维护难度。可以借鉴validation framework的Javascript Validator Tag。

4.2 Struts TagLib
struts提供了一组可扩展的自定义标签库（TagLib），可以简化创建用户界面的过程。目前包括：Bean Tags，HTML Tags，Logic Tags，Nested Tags，Template Tags　这几个Taglib。有关Struts Taglib的结构和使用，可以参考前面有关Cutomer Tag Lib的介绍，有关起详细资料，请参考

4.3 BeanUtils
这个组件的全称是Bean Introspection Utilites。是属于Jakarta Commons项目组的。主要是帮助构建javabean的属性操作的（getter,setter），已经提供一种动态定义和访问bean的属性。有关详细信息，请参考。
http://jakarta.apache.org/commons/beanutils.html
如果各位对这方面有很兴趣，可以参考一些有关java反射（Reflectio）方面的资料。

4．4 Collections
这个组件主要是提供了一些集合或列表对象，在原有的java collections framework的基础上进行了扩展。详细资料请参考：
http://jakarta.apache.org/commons/collections.html 以及
http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons/collections/STATUS.html?rev=1.13

4．5 Digester
这个组件翻译成中文的意思是“汇编”。其主要功能是根据xml配置文件，初始化系统的一些java类对象。Digester帮助你指定XML与java对象之间映射模型，而且允许客户话定制映射规则（rules）。详细资料请参考
http://jakarta.apache.org/commons/digester.html

4．6 其他相关组件
由于篇幅问题，还有一些组件就不一一介绍了，包括Database Connection Pool，Upload，Logging，Pool，Services。基在struts用户手册都有详细介绍，请参考。


五、 Struts配置文件简介（Deployment Description）
struts framework根据配置文件指定（更确切的说，是控制器），才使得ServletAction，ＡctionMapping,Action　,　ActionForm这几个不同层次的组件相互交互，协调的工作。前面也提到了，这些配置文件是在系统启动的时候，读入导内存中，供控制器使用的。
Struts framework主要包括三部分的配置描述，一个是指定有关Struts Controller及其相关的的配置描述（Initialization Parameters），一个时对struts tag lib的描述，一个是struts组件（ＡctionMapping,Action，ActionForm）之间相互映射协调的关系

5.1有关Struts Controller及其相关的的配置描述
因为Struts Controller的主要类ActionServlet是继承自HttpServlet，所以必须像配置一个Servlet那样配置ActionServlet类及其访问映射。详细信息请参考：
http://jakarta.apache.org/struts/userGuide/building_controller.html#dd_config

5.2 有关struts tag lib的配置描述
如果你的web application打算使用Struts的taglib，那么你有必要在web.xml中对struts taglib进行配置描述。有关详细的描述和说明请参考
http://jakarta.apache.org/struts/userGuide/building_controller.html#dd_config_taglib

5.3 有关Struts Action Mapping的配置描述
Struts本身有一个配置文件，通常情况为struts-config.xml。有关其DTD文档的描述，请参考http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd
（或struts-config_1_0.dtd）
一般struts-config（version1.1）包含了如下几个部分：
（1）form-bean
（2）global-forwards
（3）action-mappings
（4）data-sources
有关详细信息请参阅
http://jakarta.apache.org/struts/userGuide/building_controller.html#config

有必要提一下的是，在struts1.1中，提出了对Multiple Application Support。在struts的早先版本中，只有一个struts配置文件，一般叫struts-config.xml。但是，对于越来越复杂的应用系统的发展，只有一个地方存放这个一个文件，对大型项目来说，使用和修改这个配置文件，使其成为了一个应用的瓶颈问题。在struts1.1中，你可以定义多了配置文件协同工作。

总结
希望通过以上的对Struts Framework的讲解，读者可以对Struts的整体结构有个比较清晰的认识，对其如何处理客户请求，如何进行业务逻辑的处理和自动流转能够有个概念上的认识

------

回复此文章 |
回复主题:Re:Struts的体系结构(学习转发） | 作者: haohao | 军衔:六级军士 | 发表时间:2004-06-23 23:35:27
Struts开发过程
从Struts发布的版本号可以看出，Struts是个新玩意，她有好几个部分组成，明智的你如果搞清楚了何时该开发完成合适的部分，那将会更好的利用我们的开发时间。从我所开发的几个利用Struts应用中，我大致总结出如下这个比较有效的开发步骤：
1，明确应用需求；
2，由用户输入和获取数据的角度出发，明确和设计出每一个用户界面；
3，确定用户界面的进入路径；
4，由应用逻辑信息确定动作映射表(ActionMapping)；
5，由设计完成的用户界面开发其所用到的类和应用函数；
6，由用户界面中的数据信息开发ActionForm和相应的数据校验方法；
7，ActionMapping中将会被调用相应的Action或转到相应的JSP页面，这一步我们先开发这些Action；
8，开发商业应用逻辑，就是相应的JavaBean、EJB或其他东东；
9，开发由ActionMapping定义的系统工作流程完成对应的JSP页面；
10，完成系统配置文件：struts-config.xml和web.xml；
11，编译/测试/发布。

明确应用需求
开发任何应用系统的第一步就是收集用户需求信息。不管一个用户逻辑初看上去多么合理，但总有可能在开发时才发现它比看上去要难得多。所以，建议拟一份明确的用户需求列表，这不只是出于开发的目的，还能通过该表分析用户需求以确定哪些地方可能需要花更多的精力。
在我们这个StrutsSample项目中，应用需求就是：
作为一个展示Struts框架应用的完整例子，本示例完成的功能是用户登录。目的只为明确Struts的应用，本示例将不会涉及到一般复杂应用系统中可能应用的安全、数据库、EJB开发等等相关技术。

设计用户界面
这个应用中，包括如下三个用户界面：
1）登录界面，用于用户名和密码输入；
2）当登录用户为合法用户时的欢迎界面；
3）当登录失败时的错误提示界面。

确定用户界面的进入路径
1）登录界面作为这个应用的默认页面；
2）欢迎界面只有当成功登录后才能进入；
3）任何可能发生错误的页面能可以进入错误提示界面；

由应用逻辑信息确定ActionMapping
ActionMapping为整个应用确定的“线路图”，在配置文件struts-config.xml对ActionMapping进行定义，通过转发请求（forward）来理顺应用的处理流程，确定应用中每个用户请求对应的动作。
通常我们在开发过程中就逐步确定了ActionMapping所需的信息，开发代码的过程就是在由草稿开始一步步完善struts-config.xml的过程。当Action类处理完用户请求后，其返回的的forward就是在ActionMapping中定义的一个。一个Action返回的forward完全有多种可能，尽管一个Action一般只定义其相关的几个forward。那么，如果有多个Action都可能返回的同一个forward，那么就可以将其定义为全局转发（global forward）。这类似于C中的头文件中全局变量，如果在struts-config.xml描述信息中，某一个forward并不是在当前Action描述中定义的而是全局定义的，那么这个全局的将起作用，同样，一个Action中当前定义的forward将覆盖全局定义。在我们所给的这个简单实例中，我们定义了全局forward――“error”，当某Action返回的forward是“error”这个映射，那么Errorpage.jsp页面将会显示给用户，尽管当前Action并没有对其定义。
我们继续不断的开发，项目日渐完善，项目相关的配置文件也会越来越详细。在下面的例子中，我们将以StrutsSample中用到的struts-confug.xml文件为例，学习global forward和一个Action中相关映射的定义。下面定义了一个名为“login”的Action，其为com.oreilly.actions.LoginAction的实例，当Action处理用户登录成功后将一个名为"success"的forward返回，用户也就会看到Welcome.jsp页面，如果登录失败，Action将返回对应的forward以再显示Login.jsp给用户，而如果处理过程中发生其他错误，Action将返回全局定义的forward――“error”，用户也就会看到错误提示页面Errorpage.jsp。

<!-- ========== Global Forward 定义 -->
<global-forwards>
<forward name="login" path="/Login.jsp"/>
<forward name="error" path="/Errorpage.jsp"/>
</global-forwards>

<!-- ========== Action Mapping 定义 -->
<action-mappings>
<!-- <action>元素的相关属性 -->
<!--
以下只列出常用属性，其他请参考org.apache.struts.action.ActionMapping的相关文档

path - 当前Action对应的用户请求URI路径

type - 实现当前Action的Java class的完整名字

name - 当前Action中用到的ActionForm的名字，其具体信息在配置文件其他地方另有详细定义

unknown - 如果将该属性设置为true，那么就是声明这个Action将处理整个应用中所有未找到相应处理Action的请求，当然，一个应用系统中也只会有一个Action的unknown属性可以设为true

scope - Action中所用到的ActionForm的生存期，可以为“request”或“session”，随着生存期的设置，该Action也会在相应的时间被创建

input - 该Action中相关ActionForm获取用户输入的输入页面，当将ActionForm设为自动验证输入数据，发现不合法数据返回错误时，将返回该页面

validate - 如果本属性为true则在Action动作之前其对应的ActionForm的validate方法会自动被调用，一般用以验证用户输入的数据

forward 元素 - 定义当前Action相关的ActionForward
-->

<!-- =================== -->
<!-- O'Reilly Struts Sample Main Actions -->
<!-- =================== -->
<action path="/login"
type="com.oreilly.actions.LoginAction"
name="loginForm"
scope="request"
input="/Login.jsp">
<forward name="success" path="/Welcome.jsp"/>
<forward name="failure" path="/Login.jsp"/>
</action>
</action-mappings>

在前一篇文章中，我们曾说过，struts-config.xml就是MVC模式的的Controller。在确定struts-config.xml中的配置信息时，应该多花些时间精力在上面，以保证每一个Action定义及其相关定义是符合应用的需求的。如果在项目开始没有详细的设计其定义，当将所有代码和配置集成到一起的时候，我们将不可避免的将各部分的代码和配置完全重新组织一遍。
我们当前的例子StrusSample因为只是处理用户登录，所以只需要一个Action。一个应用系统中所要用到的Action的多少完全依应用的大小而定。一旦整套Action的映射完全的定义出来后，我们就可以一个一个开发其具体实现的Action和ActionForm类，并逐渐将完成的部分一点一点集成起来。

由设计完成的用户界面开发其所用到的类和应用函数
所有ActionForm的实现类都是org.apache.struts.ActionForm的子类。一个ActionForm是与页面上的输入表单相关联的，而且ActionForm的实现还可以对用户输入数据的合法性进行验证。作为一个Java Bean，ActionForm有Set和Get方法，当一个页面中表单被提交时，系统将自动调用Set方法将数据放入ActionForm中，而Get方法将为在Action中操作这些数据所提供。一般来说，处理表单中的所有数据，并进行合法性验证都完全可以交由ActionForm来完成。在应用中，就我个人而言，倾向于将ActionForm和Action划分到不同的包中，因为当一个页面中要用到几对ActionFrom和Action时，都放在一个包内会混淆的。下面的代码，就是实例中登录页面用到的ActionForm的代码。

/*
* LoginForm.java
*/
package com.oreilly.forms;

import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.ActionError;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;

/**
* 验证用户要用到的两个数据
*
* username - 登录用户名
* password - 用户密码
*
*/
public final class LoginForm extends ActionForm {
private String userName = null;
private String password = null;

/**
* userName的Get方法
* @return String
*/
public String getUserName() {
return (userName);
}

/**
* userName的Set方法
* @param userName
*/
public void setUserName(String newUserName) {
userName = newUserName;
}

/**
* password的Get方法
* @return String
*/
public String getPassword() {
return (password);
}

/**
* password的Set方法
* @param password
*/
public void setPassword(String newPassword) {
password = newPassword;
}

/**
* 重置所有数据
*
* @param mapping 当前的ActionMapping
* @param request 当前Server正在处理的HttpServletRequest
*/
public void reset(ActionMapping mapping, HttpServletRequest request) {
userName = null;
password = null;
}

/**
* 验证当前HTTP请求提交上来的数据
* 如果数据验证发现不合法数据，将返回一个封装
* 所有验证错误的ActionErrors对象
* 如果数据验证通过，该方法返回null或者一个
* 没有封装任何验证错误的ActionErrors对象
*
* @param mapping 当前的ActionMapping
* @param request 当前Server正在处理的HttpServletRequest
*/
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request) {
ActionErrors errors = new ActionErrors();
// 当前ActionForm中，只需要检查用户输入的用户名数据
if( userName == null || userName.length()==0 ){
errors.add("userName",new ActionError("error.userName.required"));
}
return (errors);
}
}

以上的代码，只有两点和一般的Java Bean有所不同。其一是reset方法，方法中设置的值将在表单被reset时反应到其对应的表单项上，即将表单项的数据恢复到默认值。其二是validate方法，是用来验证用户在表单中所输入数据的方法。在当前这个例子中，我们只验证用户输入的用户名。因为一个用户名其对应的密码可能为空，所以我们的逻辑就是验证时不去检查密码。验证用户名，当发现输入的用户名为空时，方法就会产生一个错误对象（ActionError）。
在Struts中用ActionErrors来装载多个错误，从ActionErrors结尾的那个“s”就可以知道她是一个ActionError对象的集合。在验证用户输入时，可以验证完表单中所有数据后，再将可能发现的多个错误通过ActionErrors返回给用户，这样的逻辑应该是想当然的啦，不可能用户有五个不同的输入错误，却要分五次提示，让用户修改提交五遍吧，呵呵。
同时，要知道在我们这个例子中，我们将错误信息提示给用户是通过ApplicationResource.properties文件。这个文件在Tomcat启动时通过web.xml中的定义为这个应用所使用。通常每一个应用都在其WEB-INF目录下都有web.xml文件来描述系统，而关于部署应用时具体的结构信息，请参考Tomcathttp://jakarta.apache.org/tomcat/index.html等Server相关的用户手册。
ApplicationResource.properties文件中可以定义应用中所要用到的提示信息的字符串，字符串都通过一个键值来唯一确定其位置。在我们这个例子中，键值error.userName.required所对应的字符串信息是“A username is required”，在给用户显示错误信息时，也就通过键值确定的错误提示显示该字符串。通过这样的机制，为我们在系统中实现多语言提供了便利，将该文件中的这些字符串翻译成相应的语言，我们的系统就可以实现西班牙语、德语、法语和汉语等等语言的版本了。
下面这些ApplicationResource.properties中的信息对于我们这个简单的示例中已经够用了：

login.title=Login Struts Sample
error.userName.required=A username is required
error.login.authenticate=Invalid username/password
errors.footer=</ul><hr>
errors.header=<h3><font color="red">Page
Validation</font></h3>Please correct the
following error(s) before contiuing:<ul>
applicationResources=Cannot load application resources bundle
{0}

页面的标题，按钮或其他什么需要文本提示的地方都可以通过这个文件来定义显示用字符串。我们将在该系列的最后一篇文章，也就是后续几个开发步骤中讲解如何通过Struts的标签从这个文件中获取显示用字符串