struts1源码分析(一)整体概览和核心组件

       今年12月Apache官方正式宣布Struts1 EOL( End-of-Life)，标志着这个里程碑式的框架正式告别历史舞台。从Struts1第一版发布，至今已十来余年，Apache在2008年底发布了最后一个版本1.3.10。这几年随着Struts2和Spring MVC等框架的红红火火，Struts1已被人慢慢淡忘。 从今天的角度来看Struts1，或许你能提出一堆设计上的问题，但每个框架背后都有特定的历史背景和存在价值，Struts1也不例外。因为手上维护的遗留项目中目前还在使用Struts1，加上最近给团队分享一些web开发基础知识，所以有机会重拾Struts1，期间看了一些源码，希望能给后来的人一些参考。

 

一、问题

作为一个MVC框架，通常需要面对下面几个问题：

1) 如何提供一个入口，让用户在web应用中引入框架?

2) 如何让用户便捷地拿到请求中的数据？

3) 如何设计统一的业务接口，方便用户使用？

4) 如何让用户灵活地进行流程控制？ 针对某个请求，调用某个业务逻辑，返回某个视图？

带着这几个问题，我们首先介绍Struts1的核心组件。

二、核心组件

       Struts1核心组件类图如下:

 

下面详细说明这几个核心组件类的作用。

1) ActionServlet

ActionServlet是整个Struts框架的入口，它继承HttpServlet类, 有两个重要职责:

1. 框架的初始化

初始化包括读取配置文件，完成各个组件和外部资源初始化等工作。 由于本身是一个servlet，这些工作都放在init()方法中完成，并只会运行一次。

2. 所有请求的入口

ActionServlet重载了doGet()和doPost()方法，负责完成对Http请求的处理。

ActionServlet承担了框架初始化和请求处理这两条主线的职责，而这两条主线的划分依据是以Servlet对象不同方法的生命周期，其他MVC框架也不例外，这正说明了Servlet规范是所有MVC框架的核心基础。一般情况下，在web.xml中配置ActionServlet,并将所有请求映射到该Servlet, 通过这种方式引入Struts框架。

 

2) RequestProcessor

Http请求的实际处理类。ActionServlet定义了请求处理入口，最终委托给RequestProcessor类进行处理。RequestProcessor将调用其他组件(ActionMapping/ActionForm/ActionForward/Action等)对请求进行处理，并返回处理结果。

 

3) Action

业务逻辑接口类, 使用者只需要遵循该接口来开发业务逻辑，不必关注框架的背后实现。Action类起到了适配器的作用，将 HttpServletRequest 转换为业务逻辑。这里看一下Action的请求处理接口声明：

 

    public ActionForward execute(
        ActionMapping mapping,
        ActionForm form,
        HttpServletRequest request,
        HttpServletResponse response)

 再看一下原生的Servlet请求处理接口声明：

 

 

protected void service(HttpServletRequest req, HttpServletResponse resp)

通过比较可以发现，Struts Action的请求处理接口在设计上比原生servlet更灵活和易用。通过引入两个新参数和返回值，可以将流程控制、请求数据处理等工作交由框架来完成。

 

4) ActionMapping

用于保存框架对特定请求的处理流程配置信息，比如特定请求如何映射到特定的Action和视图。通常在struts-config.xml配置这些信息，框架初始化时将读取这些信息并生成对应的ActionMapping实例。RequestProcessor将ActionMapping作为参数传递给Action请求处理接口，使得Action可以访问用于控制流程的配置信息。

 

5) ActionForm

用于保存请求的数据信息和辅助完成数据验证。没有ActionForm之前，请求数据都存储在HttpServletRequest对象中，提取和验证数据的工作需要手动操作HttpServletRequest对象。通过抽象出ActionForm，实现请求数据的分离，框架可以将你感兴趣的数据自动提取并填充到ActionForm对象中，使用者可以通过配置来完成对这些数据的验证。

 

6) ActionForward

用于表示当前请求的下一个目的地，比如用于最终展示的视图文件路径，或者下一步处理的路径信息。通过抽象出ActionForward，使得开发者可以从请求处理的控制逻辑中摆脱出来。如果一个请求需要多个Action参与，只需要在每个Action配置相应的ActionForward信息，由框架来组装请求处理的实际调用逻辑。

 

三、核心流程

上面介绍了框架的核心组件类图，下面从一个典型的请求处理过程来说明这些组件是如何工作的。


 

1. 用户在客户端发起请求，容器接收请求并交由ActionServlet处理(通过web.xml配置)。

2. ActionServlet在初始化时读取配置文件struts-config.xml， 完成各组件的初始化。ActionServlet将请求转交由RequestProcessor处理。

3.RequestProcessor根据请求路径信息，获取当前路径对应的ActionMapping对象，从ActionMapping中获取对应的ActionForm和Action配置。

4. RequestProcessor从请求中提取数据，生成并填充ActionForm对象。

5. RequestProcessor调用Action，开始业务逻辑调用。

6. Action从ActionForm中读取数据，完成请求数据读取和验证。

7. Action调用JavaBean，完成业务逻辑调用。

8. Action执行完毕后，返回ActionForward，交由RequestProcessor继续处理。

9. RequestProcessor依据Action返回结果将请求转发给用于展示的JSP页面。

10. JSP页面调用JavaBean填充页面展示时需要的数据。

11. 容器将请求处理结果返回给客户端。

 

 四、小结

本文概要介绍了Struts1涉及的几个核心组件类，通过例子说明这些组件类在请求处理过程中的作用。从今天角度看，Struts1在设计上有很多问题（如对servlet接口和框架的耦合等），但在当时背景下它是对MVC和Model2的一个有力的诠释。框架在不停的变化，背后的那些思想是我们需要仔细品味的。理解Struts1背后的故事，可以帮助我们更好的理解MVC框架的发展历程，以及为什么Struts2/Spring MVC等新的MVC框架能取而代之。后续将从初始化和请求处理两条主线来分析框架背后的实现。