struts1
2001年6月发布struts1
struts1的核心是控制器，由两部分组成：核心控制器和业务逻辑控制器，核心控制器是ActionServlet，由struts1提供；业务逻辑控制是用户自定义的action，由应用开发者提供。
整个应用由客户端请求驱动，客户端向web发送的请求被struts1的核心控制器ActionServlet拦截，ActionServlet根据请求 决定是否调用业务逻辑控制器处理用户请求（事实上，业务逻辑控制器还是控制器，它只是负责调用模型来处理用户请求），当用户请求处理完后，其处理结果通过 jsp呈现给用户。
如果用户只是希望得到某个url资源，得有ActionServlet将被请求的资源转发给用户。
struts1中的mvc ：
1）struts1的model部分主要由底层的业务逻辑组件充当，这些业务逻辑组件封装了底层数据库访问、业务逻辑方法实现。对于一个成熟的企业应用而 言，model部分不是一个简单的javabean所能完成的。总之，model部分封装了整个应用的所有业务逻辑，但整个部分并不是struts1提供 的，struts1也没有为实现model组件提供任何支持。
2）struts1的view部分采用jsp实现。提供了标签库，能减少脚本的使用。标签库可以输出控制器的处理结果。
但struts1锁支持的表现层技术非常单一：既不支持FreeMarker、Velocity等模版技术，也不支持JasperReports等报表技术
3）struts1的核心控制器ActionServlet继承HttpServlet类，因此可配置为标准的servlet，负责拦截所有的http请求
业务逻辑控制器负责处理用户请求，但其自身并不具有处理能力，而是调用model来处理请求
不得不佩服struts1设计者高度解耦的设计：控制器并没有直接转发请求，而仅仅返回一个ActionForward对象（可理解为逻辑视图名）--实 际的转发放在配置文件struts-config.xml中进行管理，配置文件中定义了逻辑视图名与视图资源之间的对应关系。当 ActionServlet得到处理器返回的ActionForward对象后，根据对应关系，将视图资源呈现给用户。
struts1的种种缺陷 ：
1）支持的表现层技术单一
struts1只支持jsp作为表现层技术，不提供表现层技术的整合。出现年代太早，当时还没有出现FreeMarker、Velocity等技术
2）与servlet API严重耦合，难于测试
因为struts1是在model2的基础上发展起来的，因此它完全是基于Servlet API的，所以在struts1的业务逻辑控制器内，充满了大量的servlet API
action中的参数，通常web容器负责初始化，HttpServletRequest和HttpServletResponse都是servlet API，严重依赖web服务器，因此，一旦脱离web容器，测试action非常困难。
Action代码片段：
- //业务逻辑控制器必须继承struts1的Action类
- public class LoginAction extends Action
- {
- //处理用户请求的execute方法
- public ActionForward execute(ActionMapping mapping, ActionForm form,
- HttpServletRequest request, HttpServletResponse response) throws
- AuctionException
- {
- //获取封装用户请求参数的ActionForm对象
- //将其强制转换为登陆用的ActionForm
- LoginForm loginForm = (LoginForm)form;
- //当用户名为scott,密码为tiger时，返回成功
- if ( "scott" .equals(loginForm.getUsername()
- && "tiger" .equals(loginForm.getPassword())
- {
- //处理成功，返回一个ActionForward对象
- return mapping.findForward( "success" );
- }
- else
- {
- //处理失败，返回一个ActionForward对象
- return mapping.findForward( "false" );
- }
- }
- }
3）代码严重依赖struts1 API，属于侵入式设计
struts1的action类必须继承struts1的action基类，实现处理方法时，又包含了大量的struts1 API：ActionMapping、ActionForm、ActionForward。
这种侵入式设计的最大弱点在于，一旦系统需要重构，这些action类将完全没有利用价值，成为废品。
可见，struts1的action类的这种侵入式设计 导致了较低的代码复用。
------------------------------
webwork
采用更加松耦合的设计，系统的action和servlet API不在耦合，使单元测试更方便，允许系统从B/S结构向C/S结构转换
webwork支持更多的表现层技术，如velocity，freemarker和xslt等
webwork可以脱离web应用使用，webwork有自己的控制反转（Inversion of Control）容器，通过控制反转，能让测试更简单
从处理流程上来看，webwork与struts1很相似，核心都是控制器组成：
1）核心控制器ServletDispatcher，由框架提供
2）业务逻辑控制器Action，由程序员提供
相对于struts1，webwork优点
1）action无需与Servlet API耦合，更容易测试
2）action无需与webwork耦合，代码重用率高
仅仅实现webwork的action接口，包含了一个execute方法。
实现一个接口和继承一个类是完全不同的概念，实现一个接口对类的污染小的多，该类可以实现其他任意接口，还可以继承一个父类；但一旦已经继承了一个父类，则意味着该类不能在继承其他父类。
3）支持更多的表现层技术，有更好的适应性
----------------
struts2
2006年
struts2的大致处理流程如下：
1）浏览器发送请求，例如请求/mypage.action、/reports/myreport.pdf
2）核心控制器FilterDispatcher根据请求决定调用合适的Action
3）webwork的拦截器链自动对请求应用通用功能，例如：workfolw、validation或文件上传等功能
4）回调Action的execute方法，该execute方法先获取用户请求参数。实际上，因为Action只是一个控制器，它会调用业务逻辑组件来处理用户的请求
5）Action的execute方法处理结果信息将被输出到浏览器中，此时支持的视图技术非常多。
struts2的配置文件有两份：
1）配置Action的struts.xml文件
2）配置struts2全局属性的struts.properties
定义action的处理结果时，可以指定多个result，result元素指定execute方法返回值和试图资源之间的映射关系。
<result name="cancel" type="redirect-action">Welcome</result>
定义result元素时，可以指定两个属性：type和name，其中name指定execute方法返回的字符串，type指定转向的资源类型，可以是 jsp，也可以是freemarker等，甚至是另一个action，这也是struts2可以支持多种视图技术的原因。
struts2的控制器组件：
所有的MVC框架都是以控制器组件为核心，struts2的控制器有两部分组成：FilterDispatcher和业务控制器Action。
实际上，struts2中起作用的业务控制器不是用户定义的Action，而是系统生成的Action代理，但该Action代理以用户定义的Action为目标。
通过查看action代码发现，struts2的action比webwork的action更彻底，该action无需实现任何父接口，无需实现任何struts2基类，该action完全是一个POJO（普通、传统的java对象），具有很好的复用性。
归纳起来，struts2的action具有如下优势：
1）action类完全是一个pojo，因此具有很好的代码复用性；
2）action类无需与servlet API耦合，因此进行单元测试非常简单
3）action类的execute方法就仅返回一个字符串作为处理结果，该处理结果可映射到任何的结果，甚至是另一个action
-------------------------
struts1和struts2的简要对比：
1）action实现类方面的对比：struts1要求action类继承一个抽象基类，是使用抽象类编程而不是接口；struts2 action类可以实现一个action接口，也可以实现其他接口，使可选和定制的服务成为可能。struts2提供一个ActionSupport基类 去实现常用的接口。但即使是这个action接口也不是必须实现的，只要是一个包含execute方法的pojo类，都可以用作struts2的action 。
2）线程模版方面的对比：struts1 action是单例模式并且必须是线程安全的，因为仅有action的一个实例来处理所有请求。单例策略限制了struts1 action能做的事，并且要在开发式特别小心。action资源必须是线程安全的；struts2 action为每一个请求产生一个实例，因此没有线程安全问题。
3）servlet依赖方面的对比：struts1 action依赖servlet API；struts2 action不在依赖于servlet api，从而允许action脱离web容器运行，降低测试难度。
4）可测性方面的对比：struts1 action的容器，脱离web容器测试struts1 action需要借助于第三方扩展 struts testcase；struts2 action可通过初始化，设置属性，调用方法来测试。
5）封装请求参数的对比
6）表达式语言方面的对比：struts1 整合了JSTL ，struts2也可以使用JSTL，而且整合了一种更强大和灵活的表达式语言：OGNL
7）绑定值到视图的对比：struts1使用标准JSP机制把对象绑定到视图页面；struts2使用“ValueStack”技术，使标签库能访问值，而不需要把对象和视图页面绑定到一起。
8）类型转换的对比：Stuts1的actionForm的属性通常都是String类型，struts1使用comments-beanutils进行 类型转换，每个类一个转换器，转换器是不可配置的；struts2使用OGNL进行类型转换，支持基本数据类型和常用对象之间的转换。
9）数据校验对比：struts1支持在actionFrom重写validate方法中手动校验，或者通过整合Commons alidator框架来完成数据校验。struts2支持重写validate方法进行校验，也支持整合xwork校验框架进行校验。
10）action执行控制的对比：struts1支持为每个模块对应一个请求（即生命周期的概念），但模块中的所有action必须共享相同的生命周 期。struts2支持通过连接器堆栈（Interceptor Stacks）为每个action创建不同的生命周期。
-------------------
webwork和struts2对比：
struts2不在支持内建的ioc容器，而改为全面支持spring的ioc容器，以spring的ioc容器作为默认的object工厂。
