请求运作过程
在我们开始详细探讨如何把应用由Struts迁移到Struts 2之前，让我们通过体验整个请求流程，看看新架构是如何运作的。
在我们体验了整个请求的生命周期后，你应当注意到很重要的一点——Struts 2仍是以前端控制器框架为主体的。所有的概念还都是你以前所熟悉的。
这意味着：
- Actions仍然是通过URL触发的
- 数据仍然是通过URL请求参数和Form参数传送到服务端的
- 所有Servlet对象（如request、response和session等）仍在Action可用
以下是请求处理过程的高层概览：
整个请求的处理过程可以分为6步：
- 由框架产生一个请求并进行处理 - 框架根据请求匹配相应的配置，得到使用哪些拦截器，Action类和返回结果的信息。
- 请求通过一系列的拦截器 - 拦截器和拦截器组可以按照不同级别进行组合配置来处理请求。它们为请求提供各种预处理和切面处理的应用功能。这和Struts的使用Jakarta Commons Chain构件的RequestProcessor类很相似。
- 调用Action - 产生一个新的Action对象实例，并提供请求所调用的处理逻辑的方法。我们在第二部文章中将对这步骤进行进一步讨论。Struts 2可以在配置Action时为请求分配其指定的方法。
- 调用相应的Result - 通过匹配处理Action方法之后的返回值，获取相应Result类，生成并调用它的实例。处理Result可能产生的结果之一就是对UI模板（但并非只有一个）进行渲染，来产生HTML。如果是这种情况的话，模板中的Struts 2 tags可以直接从Action中获取要被要被渲染的值。
- 请求再次经过一系列拦截器处理后返回 - Request以和进入时相反的方向通过拦截器组，当然，你可以在这个过程中进行回收整理或者额外的处理工作。
- 响应被返回给用户 - 最后一步是将控制权交还给Servlet引擎。最常见的结果是把渲染后的HTML返回给用户，但返回的也可能是指定的HTTP头或者进行HTTP重定向。
你应该已经注意到Struts 2和Struts的差别了。最明显的就是Struts 2是一个pull-MVC架构。这是什么意思呢？从开发者角度看，就是说需要显示给用户的数据可以直接从Action中获取，而不像Struts那样必须把相应的Bean存到Page、Request或者Session中才能获取。
