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框架能取而代之。后续将从初始化和请求处理两条主线来分析框架背后的实现。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值