Struts快速入门（三）

利用ActionMapping的命令模式

Struts提供一个公开的基于XML语句的方法来说明请求URI中servlet路径与适当的请求处理器之间的映射。这个实现与命令模式[Gof]很相似。以下片断摘自struts-config.xml文件，下列声明用于建立ActionMapping配置对象，它是元素的运行时表现。

type="packageName.EditCustomerProfileAction"

name="customerProfileForm"

scope="request"/>

以下简要说明上述声明中用到的属性。

path：HTTP请求中虚拟目录的相对路径，用于识别这个动作映射。

type：类名，将用于在处理这个请求的时候建立一个请求处理器实例。

name：JavaBean的逻辑名称，也叫做表单bean，将用于保存表单数据。表单bean将用这个名称保存在指定的范围（scope）中。

scope：保存bean时用请求或会话范围。

上例中Path属性映射到HTML文件中

元素的 action 属性。在上面范例中避免了硬代码映射到代码内部而且可以方便的看到 HTML 表单中的 servlet 路径如何映射到请求处理器的实例。另外，应用系统行为和导航语义可以方便的通过修改动作映射来完成。请求处理器是 Struts 提供的 Action 类的子类。

对于HTML标签，使用自定义的org.apache.struts.taglib.html.FormTag为action属性动态生成动态URL可以保护HTML文档避免修改虚拟目录或时的大量变动。对于*.do模式的URL，下面的自定义FormTag 将使用action属性包含的如下服务器相关URL动态生成一个HTML 标签：

使用name属性，行为映射可以声明一个特定的JavaBean ，其特性将保存来自HTTP请求的参数，该JavaBean是ActionFrom类的子类。行为映射声明中的name属性是在特定范围内使用哪个ActionForm类的实例保存的唯一标示。ActionForm子类使用标签声明于struts-config.xml文件中，如下：

参阅“获取表单数据”章节以得到关于元素和ActionForm类的更多信息。

模型与请求处理器的相互作用

Action的一个子类是用于作为提交的请求和模型之间的适配器。Action子类，也叫做请求处理器，是为每个请求特别建立的。一个动作最初被RequestProcessor解释，然后轮流实例化一个相应的请求处理器。这个Action类的对象为每个请求特别建立，已经在前面章节中的发送者阐述。请求处理器实现了命令模式[Gof]。一个终端请求在请求URL中封装了欲执行的行为即servlet路径，该路经信息随后被发送者（RequestProcessor）提取以建立一个相应的请求处理器实例。命令模式消除了用户界面（UI）对请求处理器的影响。

基本的Action类提供访问架构相关资源的常用函数以及保存使用其子类的execute(…)方法而产生的错误的方法。该错误随即通过采用定制的org.apache.struts.taglib.html.ErrorsTag，被获取并显示到HTML表单。请求处理器的execute(…)方法应该包含处理请求参数和相关ActionForm的控制流程，它应该封装模型相关语义，并且应该在模型操作结果的基础上提供下一个视图。请求处理器在第一次建立后就被RequestProcessor捕获，随即被设为对其他的提交请求可用；同样的，请求处理器必须不含有用户特定的状态信息；请求处理器也必须同步化访问需要串行访问的资源。对于一个分布式应用，动作类包括与EJB组件中的事务逻辑相关联的控制逻辑且一般采用Business Delegate[Core]对象来实现该目的。事务委托保护请求处理器免于处理访问分布式组件的复杂度。因为访问服务器端组件的逻辑被嵌入到事务委托中，事务委托设计模式促进了请求处理器与服务器端组件的松散耦合。请求处理器由表示层工作的开发者编写，然而事务委托常常由负责建立事务层服务的开发者编写。对于小型非分布式应用，动作类或许包含事务逻辑。当分布式处理不是必需的且事务逻辑被嵌入在请求处理器中时，Data Access Object [Core]可以用于抽象潜在的数据访问实现，它为请求处理器与数据访问层提供了松散的耦合，从而保护表示层避免在整合层中改变实现。请求处理器基本的Action类提供部分方便的方法，请查阅API文档位于：http://jakarta.apache.org/struts/api/index.html。