1.Struts 2的基本流程
  Struts 2框架由3个部分组成：核心控制器FilterDispatcher、业务控制器和用户实现的业务逻辑组件。在这3个部分里，Struts 2框架提供了核心控制器FilterDispatcher，而用户需要实现业务控制器和业务逻辑组件。
2.核心控制器：FilterDispatcher
  FilterDispatcher是Struts 2框架的核心控制器，该控制器作为一个Filter运行在Web应用中，它负责拦截所有的用户请求，当用户请求到达时，该Filter会过滤用户请求。如果用户请求以action结尾，该请求将被转入Struts 2框架处理。

Struts 2框架获得了*.action请求后，将根据*.action请求的前面部分决定调用哪个业务逻辑组件，例如，对于login.action请求，Struts 2调用名为login的Action来处理该请求。

Struts 2应用中的Action都被定义在struts.xml文件中，在该文件中定义Action时，定义了该Action的name属性和class属性，其中name属性决定了该Action处理哪个用户请求，而class属性决定了该Action的实现类。

Struts 2用于处理用户请求的Action实例，并不是用户实现的业务控制器，而是Action代理——因为用户实现的业务控制器并没有与Servlet API耦合，显然无法处理用户请求。而Struts 2框架提供了系列拦截器，该系列拦截器负责将HttpServletRequest请求中的请求参数解析出来，传入到Action中，并回调Action 的execute方法来处理用户请求。

显然，上面的处理过程是典型的AOP（面向切面编程）处理方式。图3.19显示了这种处理模型。



图3.19  Struts 2的拦截器和Action

从图3.19中可以看出，用户实现的Action类仅仅是Struts 2的Action代理的代理目标。用户实现的业务控制器（Action）则包含了对用户请求的处理。用户的请求数据包含在 HttpServletRequest对象里，而用户的Action类无需访问HttpServletRequest对象。拦截器负责将 HttpServletRequest里的请求数据解析出来，并传给业务逻辑组件Action实例。
3.业务控制器
  正如从图3.19所看到的，业务控制器组件就是用户实现Action类的实例，Action类里通常包含了一个execute方法，该方法返回一个字符串——该字符串就是一个逻辑视图名，当业务控制器处理完用户请求后，根据处理结果不同，execute方法返回不同字符串   ——每个字符串对应一个视图名。

程序员开发出系统所需要的业务控制器后，还需要配置Struts 2的Action，即需要配置Action的如下三个部分定义：

—  Action所处理的URL。

—  Action组件所对应的实现类。

—  Action里包含的逻辑视图和物理资源之间的对应关系。

每个Action都要处理一个用户请求，而用户请求总是包含了指定URL。当Filter Dispatcher拦截到用户请求后，根据请求的URL和Action处理URL之间的对应关系来处理转发。
4.Struts 2的模型组件
  实际上，模型组件已经超出了MVC框架的覆盖范围。对于Struts 2框架而言，通常没有为模型组件的实现提供太多的帮助。

文本框: 图3.20 控制器调用模型组件Java EE应用里的模型组件，通常指系统的业务逻辑组件。而隐藏在系统的业务逻辑组件下面的，可能还包含了DAO、领域对象等组件。

通常，MVC框架里的业务控制器会调用模型组件的方法来处理用户请求。也就是说，业务逻辑控制器不会对用户请求进行任何实际处理，用户请求最终由模型组件负责处理。业务控制器只是中间负责调度的调度器，这也是称Action为控制器的原因。


图3.20显示了这种处理流程。

提示  在图3.20中看到Action调用业务逻辑组件的方法。当控制器需要获得业务逻辑组件实例时，通常并不会直接获取业务逻辑组件实例，而是通过工厂模式来获得业务逻辑组件的实例；或者利用其他IoC容器（如Spring容器）来管理业务逻辑组件的实例。
5.Struts 2的视图组件
  Struts 2已经改变了Struts 1只能使用JSP作为视图技术的现状，Struts 2允许使用其他的模板技术，如FreeMarker、Velocity作为视图技术。

当Struts 2的控制器返回逻辑视图名时，逻辑视图并未与任何的视图技术关联，仅仅是返回一个字符串，该字符串作为逻辑视图名。

当我们在struts.xml文件中配置 Action时，不仅需要指定Action的name属性和class属性，还要为Action元素指定系列result子元素，每个result子元素定义一个逻辑视图和物理视图之间的映射。前面所介绍的应用都使用了JSP技术作为视图，故配置result子元素时没有指定type属性，默认使用JSP 作为视图资源。

如果需要在Struts 2中使用其他视图技术，则可以在配置result子元素时，指定相应的type属性即可。例如，如果需要使用FreeMarker，则为result指定值为freemarker的type属性；如果想使用Velocity模板技术作为视图资源，则为result指定值为velocity的type属性……
6.Struts 2的运行流程
  经过上面介绍，我们发现Struts 2框架的运行流程非常类似于WebWork框架的流程。

提示  在Struts 2的官方站点，我们可以找到如下说法：Essentially，Struts 2.0 is the technical equivalent of WebWork 2.3。Aside from the package and property renaming，it isn't much different than，say，migrating from WebWork 2.1 to 2.2——意思是说：Struts 2.0技术等同于WebWork 2.3框架，除了包和属性被改名外。从WebWork 2.2迁移到Struts 2不会比从WebWork 2.1迁移到WebWork 2.2更复杂。

这里我们可以看到，Struts 2其实就是WebWork 2.2的升级版，这也就不难理解：为什么WebWork和Struts 2如此相似！

因此，Struts 2的运行流程与WebWork的运行流程完全相同，读者可以参看图1.8来了解Struts 2的运行流程。