在上面讲解ActionServlet，Action Classes 和Action Mapping 的时候，我们都提到了ActionForm Bean 的概念。一个应用系统的消息转移（或者说状态转移）的非持久性数据存储，是ActionForm Bean 的负责保持的。ActionForm 派生的对象用于保存请求对象的参数，因此它们和用户紧密联系。
一个ActionForm 类被RequestProcessor 建立。这是发生在已完成向前进到一个URL，该URL 为映射到控制器servlet 而不是JSP 和相应的动作映射指定的表单属性的。在这个情况下，如果没有在指定的活动范围内找到，RequestProcessor 将尝试寻找可能导致创建一个新ActionForm 对象的表单bean。该ActionForm 对象在指定的活动范围内被用<action>元素的name 属性找到；
RequestProcessor 将随后重新安排表单属性，用请求时参数填充表单，随即调用表单对象的validate(… )方法以履行服务器端用户输入验证。仅当ActionMapping 对象中validate
属性被设为true 时，validate(… )方法被调用；这就是默认的行为。
request.getParameterValues(parameterName)被用于得到一个String[]对象，它用来表单填充；
验证的结果应该是一个ActionErrors 对象，用org.apache.struts.taglib.html.ErrorsTag 来显示验证错误给用户。ActionForm 也可以被用于为当前用户保存即将被一个视图引用的中间模型状态。
当一个表单对象被RequestProcessor 找到，它被传递到请求处理器的execute(… )方法。一个ActionForm 对象也可以被请求处理器建立。表单对象建立目的是提供中间模型状态给使用请求范围JSP；这将确保对象不会在有效性过期后仍然存在。默认的，所有的表单都被保存为会话范围。会话中表单对象脱离有效性的存在可能导致浪费内存，同样的，请求处理器必须跟踪保存在会话中的表单对象的生命周期。一个好的捕获表单数据的实践是为横跨多用户交互的相关表单用一个单独的表单bean。表单bean 也可以在反馈的时候用来储存能够被自定义标签改变的中间模型状态。在视图中标签用法避免结合Java 代码，因此要成一个好的任务划分，web 生产组主要处理标志，而应用开发组主要处理Java 代码。标签因素退出访问中间模型状态的逻辑；当访问嵌套的对象或当通过聚集列举时这个逻辑可能很复杂。
注意：在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()方法。
（9）如果validate（）方法没有返回任何错误，控制器将ActionForm 作为参数，传给Action 实例的execute（）方法并执行。
注意：直接从ActionFrom 类继承的reset()和validate()方法，并不能实现什么处理功能，所以有必要自己重新覆盖。