5.3.1 什么是Structs框架
Structs源于在建筑与旧式飞机中使用的支持金属架，它是由自定义标签、信息资源(message resource)、Servlet和JSP组成的一个可重用的MVC2模式的框架。以Structs 1.0为例，它的结构图如下所示：
从上图可以看出，Structs的体系结构采用了MVC设计模式，同时包含客户端(Client)请求以及业务逻辑处理(Business Logic)，而MVC设计模式主要是由模型(Model)、视图(View)和控制器(Controller)三部分组成。
下面对这些模块分别进行介绍：
1>客户端(Client)
一方面可以通过浏览器发送HTTP请求，另一方面可以把接收到的HTTP响应消息在浏览器上展现出来。
2>控制器(Controller)
控制器主要包括ActionServlet类和RequestProcessor类。其中，ActionServlet类是MVC实现的控制器部分，是整个框架的核心部分，它用来接收用户的请求，并根据用户的请求从模型模块中获取用户所需的数据，然后选择合适的视图来响应用户的请求。它采用了命令设计模式来实现这个功能：通过structs-config.xml配置文件来确定处理请求的Action类。在处理用户请求时，关于请求的处理大部分已交由RequestProcessor.process()方法来处理。RequestProcessor类的process()方法采用了模板的设计模式(按照处理的步骤与流程顺序的调用了一系列的方法)。处理的主要流程为：
1)processPath(request,response)。根据URI(Uniform Resource Identify,统一资源标识符，用来唯一的标识一个资源)来得到ActionMapping元素的路径。
2)processMapping(request,response)。根据路径信息找到ActionMapping对象。
3)processRoles(request,response，mapping)。Structs为Web应用提供了一种认证机制，当用户登录时，会通过processRoles方法调用requestisUserInRole()方法来检查这个用户是否有权限来执行给定的ActionMapping。
4)processValidate(request,response,form,mapping)。调用ActionForm的validate()方法。
5)processActionCreate(request,response,mapping)。这个方法从< action>的type属性得到Action类名，并创建返回它的实例。
6)processActionPerform(req,res,action,form,mapping)。这个方法调用Action类的execute()方法，其中execute()方法中包含了业务逻辑的实现。需要注意的是，Action类并不是线程安全的。
3>业务逻辑(Business Logic)
Servlet在接收到请求后会根据配置文件中的对应关系，把请求转给指定的Action类来处理，Action类采用适配器设计模式，它只是对业务逻辑进行了包装(真正的业务逻辑是由EJB的session bean或普通的Java类来实现)。
4>模型(Model)
在Structs体系结构中，模型分为两个部分：系统的内部状态和可以改变状态的操作(业务逻辑)。内部状态通常由一组Actionform Bean类表示ActionForm封装了HTTP请求的数据的类或对象。ActionForm是一个抽象类，每一个输入表单都对应着它的一个子类。配置文件structs-config.xml中保存了HTTP请求表单与具体ActionForm类的映射关系。
5>视图(View)
视图就是一个JSP文件，该JSP文件中没有任何业务逻辑的处理，也不保存系统的状态信息，它通过一些标签把数据以浏览器能识别的方式展现出来。目前，标签库主要有Bean Tags、HTML Tags、Logic Tags、Nested Tags以及Template Tags等。
Structs框架作为一项开放源码项目，优点众多，具体而言，主要有以下几点：
1)由于采用了MVC模式，因此它实现了表现与逻辑的分离，使得系统有较好的可扩展性。同时Structs的标记库(Taglib)包含了大量的tag，有助于提高系统的开发效率。
2)提供了页面导航功能，使系统的脉络更加清晰。通过一个配置文件建立整个系统各部分之间的联系，使系统结构变得更加清晰，从而增加了系统的可扩展性与可维护性。
3)提供了表单的验证功能，进一步增强了系统的健壮性。
4)提供了数据库连接池管理。
5)提供了Exception处理机制。
6)支持国际化。
当然，Structs也有它的不足之处，主要有以下几点：
1)Taglib中包含了大量的tag，对于初学者而言，开发难度比较大。
2)Structs开发中包含了许多XML格式的配置文件。一方面，这些配置文件不易调试；另一方面，大量的XML文件也不便于管理。
3)Structs只能支持Web应用程序的开发。
4)Structs的Action不是线程安全的，因此Action类用到的所有资源都必须进行同步。
5)单元测试不方便。由于Action与Web层的紧耦合，导致其非常依赖于Web容器，给单元测试带来了不便。
6)部署繁琐。当转到表示层时，需要配置forward，例如，如果有10个表示层的JSP文件，则需要配置10个Structs。此处，当目录、文件变更后，需要重新修改forward，而且每次修改配置之后，还需要重新部署整个项目，对于Tomcat等服务器，还必须重启服务器。
7)对Servlet的依赖性过强。Structs处理Action时必须依赖ServletRequest和ServletResponse，摆脱不了对Servlet容器的依赖。
5.3.2 Structs框架响应客户请求的工作流程是什么
在Structs框架中，控制器主要是ActionServlet，但是对业务逻辑的操作则是主要由Action、ActionMapping、ActionForward等组件协调完成。其中，Action扮演了真正的控制逻辑实现者的角色，而ActionMapping和ActionForward则制定了不同业务逻辑或流程的运行方向。
对于采用Structs框架的Web应用而言，在Web应用启动时，会加载并初始化ActionServlet，ActionServlet从structs-config.xml文件中读取配置信息，并把他们存放到ActionMappings对象中。具体而言，当Application接收到一个客户请求时，执行如下流程：
1>检索和用户请求匹配的ActionMappings实例，如果不存在，就返回用户请求路径无效的信息。
2>如果ActionForm实例不存在，就创建一个ActionForm对象，把客户提交的表单数据保存到ActionFrom对象中。
3>根据配置信息决定是否需要表单验证。如果需要验证，就调用ActionForm的validate()方法。
4>如果ActionForm的validate()方法返回null或返回一个不包含ActionMessage的ActionErrors对象，就表示表单验证成功。
5>ActionServlet根据ActionMapping实例包含的映射信息决定将请求发送给哪个Action。如果对应的Action实例不存在，就先创建一个实例，然后调用Action的execute()方法。
6>Action的execute()方法返回一个ActionForward对象，ActionServlet再把客户请求转发给ActionFroward对象指向的JSP组件。
7>ActionForward对象指向的JSP组件生成动态页面，返回给客户。
对于以上流程中的步骤4>，如果ActionForm的validate()方法返回一个(包含一个)或多个ActionMessage的ActionError对象，就表示表单验证失败，此时，ActionServlet将直接把请求转发给包含客户提交表单的JSP组件。在这种情况下，不会再创建Action对象并调用Action的execute()方法了。