Struts1和Struts2的比較

特性	Struts 1	Struts 2
Action類	Struts 1要求Action類要擴展自一個抽象基類。Struts 1的一個共有的問題是面向抽象類編程而不是面向接口編程。	Struts 2的Action類實現了一個Action接口，連同其他接口一起麳實現可選擇和自定義的服務。Struts 2提供一個名叫ActionSupport的基類麳實現一般使用的接口。雖然，Action接口不是必須的。任何使用execute方法的POJO對象可以被當作Struts 2的Action對象麳使用。
綫程模型	Struts 1 Action類是單例類，因爲只有一個示例麳控制所有的請求。單例類策略造成了一定的限制幷且給開發帶來了額外的煩惱。Action資源必須是綫程安全或者同步的。	Struts 2 Action對象爲每一個請求都實例化對象，所以沒有綫程安全的問題。（實踐中，servlet容器産生許多丟弃的對象對于每一個請求，多于一個的對象并不影響垃圾收集）
Servlet依賴	Struts 1的Action類依賴于servlet API以爲HttpServletRequest和HttpServletResponse作爲參數傳給execute方法當Action被調用時。	Struts 2的Action不和容器有關。Servlet上下文被表現爲簡單的Maps，允許Action被獨立的測試。Struts 2的Action可以訪問最初的請求和相應，如果需要的話。然而，其他的架構元素减少或者排除直接訪問HttpServletRequest或者HttpServletResponse的需要。
易測性	測試Struts 1的主要障礙是execute方法暴露了Servlet API。第三方的擴展，Struts測試用例，提供Struts 1的集合對象。	Struts 2的Action可以通過實例化Action麳測試，設置屬性，然後調用方法。依賴注入的支持也是測試變得更簡單。
接受輸入	Struts 1使用ActionForm對象麳捕獲輸入。象Action一樣，所有的ActionForm必須擴展基類。因爲其他的JavaBean不能作爲ActionForm使用，開發者經常創建多余的類麳捕獲輸入。DynaBeans可以被用來作爲替代ActionForm的類麳創建。但是開發者可以重新描述已經存在的JavaBean。	Struts 2 Action屬性作爲輸入屬性，排除第二個輸入對象的需要。輸入屬性可能有豐富的對象類型這些類型有他們自己的屬性。Action的屬性可以通過標簽庫麳訪問。Struts 2也支持ActionForm形式。豐富的對象類型，包含業務或者域對象，可以被當作輸入或者輸出對象麳使用。糢型驅動特性簡化標簽對POJO輸入對象的引用。
表達式語言	Struts 1整和JSTL，所以它使用JSTL的表達式語言。表達式語言有基本的圖形對象移動，但是相對很弱的集合和被索引的屬性支持。	Struts 2使用JSTL，但是框架也支持更强大和更靈活的表達式，叫做“對象圖形符號語言”（OGNL）。
將值綁定要視圖上	Struts 1使用標準JSP機製來綁定對象到頁面上下文。	Struts 2使用“ValueStack”技術爲了標簽庫可以不用鏈接你的視圖到對象的表現類型麳訪問值。ValueStack策略允許重用視圖。
類型轉換	Struts 1的ActionForm屬性經常都是String的。Struts 1使用Commons-Beanutils麳類型轉換。轉換每一個類，幷不是爲每一個實例配置。	Struts 2使用OGNL麳類型轉換。框架包含轉換器麳爲基本的和共同的對象類型和原始類型。
驗證	Struts 1支持手動驗證憑借ActionForm的validate方法，或者通過擴展的公用驗證器。類可以有不同的驗證上下文麳未相同的類，但是不能不能包括驗證子對象。	Struts 2支持手動驗證憑藉validate方法和XWork驗證框架。Xwork驗證框架支持一連串的驗證子屬性使用的驗證爲了屬性類的類型和嚴正上下文而定義。
Action執行的控制	Struts 1支持獨立的請求處理器對于每一個模型，但是所有在模型中的Action必須共享同一個生命周期。	Struts 2支持在每一個Action基礎上憑借攔截棧創建不同的生命周期。自定義棧可以被創建幷且使用不同的所需 的Action。

struts已经是mvc开发的标准，但随着webwork和struts的合并（Struts2），试问将来struts还用不用于开发项目,struts2是否会取代struts？

下面简单介绍写两者的区别和发展。

    struts是2001年发布的。这个发布时间比webwork早一年，IT世界就是这个原理，时间决定一切。早一分钟还晚一分钟可能会导致两重天。由于企业迫切需要个mvc开发标准，因此struts自然荣登宝座。但是虽然框架的发展，struts显出拉很多弊病。比如说它的action与serlvet严重耦合导致测试困难和扩展性受到挑战，还有貌似鸡肋的ActionForm一直是开发者疑惑的问题。但是webwork确实很好的解决拉这些问题，因为发布时间慢拉一年，导致现在发展的尴尬局面，但是不少开发者仍用webwork，由于企业界的需求，struts2诞生拉。

      经过六年多的发展，Struts1已经成为了一个高度成熟的框架，不管是稳定性还是可靠性都得到了广泛的证明。市场占有率超过20%，拥有丰富的开发人群，几乎已经成为了事实上的工业标准。但是随着时间的流逝，技术的进步，Struts1的局限性也越来越多地暴露出来，并且制约了Struts1的继续发展。

      对于Struts1框架而言，由于与JSP/Servlet耦合非常紧密，因而导致了一些严重的问题。首先，Struts1支持的表现层技术单一。由于Struts1出现的年代比较早，那个时候没有FreeMarker、Velocity等技术，因此它不可能与这些视图层的模版技术进行整合。其次，Struts1与Servlet API的严重耦合，使应用难于测试。最后，Struts1代码严重依赖于Struts1 API，属于侵入性框架。

        从目前的技术层面上看，出现了许多与Struts1竞争的视图层框架，比如JSF、Tapestry和Spring MVC等。这些框架由于出现的年代比较近，应用了最新的设计理念，同时也从Struts1种吸取了经验，克服了很多不足。这些框架的出现也促进了Struts的发展。目前，Struts已经分化成了两个框架：第一个是在传统的Struts1的基础上，融合了另外的一个优秀的Web框架WebWork的Struts2。Struts2虽然是在Struts1的基础上发展起来的，但是实质上是以WebWork为核心的。Struts2为传统的Struts1注入了WebWork的先进的设计理念，统一了Struts1和WebWork两个框架。Struts1分化出来的另外一个框架是Shale。这个框架远远超出了Struts1原有的设计思想，与原有的Struts1关联很少，使用了全新的设计思想。Shale更像一个新的框架而不是Struts1的升级。 本文下面的内容将主要讨论Struts2。

二．Struts2体系结构

Struts2的体系与Struts1体系的差别非常大，因为Struts2使用了WebWork的设计核心，而不是Struts1的设计核心。Struts2中大量使用拦截器来处理用户的请求，从而允许用户的业务逻辑控制器与Servlet API分离。图一是Struts2的体系结构简图。

Struts2框架的大概处理流程如下：

1. 浏览器发送一个请求。
2. 核心控制器FilterDispatcher根据请求决定调用合适的Action。
3. WebWork的拦截器链自动对请求应用通用功能，如验证等。
4. 回调Action的execute方法，该execute方法根据请求的参数来执行一定的操作。
5. Action的execute方法处理结果信息将被输出到浏览器中，支持多种形式的视图。

三．Struts2和Struts1的对比

通过上面对Struts2体系结构的了解，我们发现Struts2对Struts1进行了巨大的改进。主要表现在如下几个方面：

1. 在Action的实现方面：Struts1要求必须统一扩展自Action类，而Struts2中可以是一个普通的POJO。
2. 线程模型方面：Struts1的Action工作在单例模式，一个Action的实例处理所有的请求。Struts2的Action是一个请求对应一个实例。没有线程安全方面的问题。
3. Servlet依赖方面：Struts1的Action依赖于Servlet API，比如Action的execute方法的参数就包括request和response对象。这使程序难于测试。Struts2中的Action不再依赖于Servlet API，有利于测试，并且实现TDD。
4. 封装请求参数：Struts1中强制使用ActionForm对象封装请求的参数。Struts2可以选择使用POJO类来封装请求的参数，或者直接使用Action的属性。
5. 表达式语言方面：Struts1中整合了EL，但是EL对集合和索引的支持不强，Struts2整合了OGNL（Object Graph Notation Language）。
6. 绑定值到视图技术：Struts1使用标准的JSP，Struts使用“ValueStack”技术。
7. 类型转换：Struts1中的ActionForm基本使用String类型的属性。Struts2中使用OGNL进行转换，可以更方便的使用。
8. 数据校验：Struts1中支持覆盖validate方法或者使用Validator框架。Struts2支持重写validate方法或者使用XWork的验证框架。
9. Action执行控制的对比：Struts1支持每一个模块对应一个请求处理，但是模块中的所有Action必须共享相同的声明周期。Struts2支持通过拦截器堆栈为每一个Action创建不同的声明周期。

四．WebWork和Struts2的对比

从某种程度上看，Struts2是从WebWork2上升级得到的。甚至Apache的官方文档也讲：WebWork2到Struts2是平滑的过渡。我们甚至也可以说Struts2就是WebWork2.3而已。在很多方面Struts仅仅是改变了WebWork下的名称。

Action 类:

? Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。

? Struts 2 Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去实现 常用的接口。Action接口不是必须的，任何有execute标识的POJO对象都可以用作Struts2的Action对象。

线程模式:

? Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。

? Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题）

Servlet 依赖:

? Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。

? Struts 2 Action不依赖于容器，允许Action脱离容器单独被测试。如果需要，Struts2 Action仍然可以访问初始的request和response。但是，其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。

可测性:

? 测试Struts1 Action的一个主要问题是execute方法暴露了servlet API（这使得测试要依赖于容器）。一个第三方扩展－－Struts TestCase－－提供了一套Struts1的模拟对象（来进行测试）。

? Struts 2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使测试更容易。

捕获输入:

? Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经常创建多余的类捕获输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述(创建)已经存在的JavaBean（仍然会导致有冗余的javabean）。

? Struts 2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型，包括业务对象，能够用作输入/输出对象。这种ModelDriven 特性简化了taglib对POJO输入对象的引用。

表达式语言：

? Struts1 整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。

? Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object Graph Notation Language" (OGNL).

绑定值到页面（view）:

? Struts 1使用标准JSP机制把对象绑定到页面中来访问。

? Struts 2 使用 "ValueStack"技术，使taglib能够访问值而不需要把你的页面（view）和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面（view）。

　

类型转换：

? Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器，对每一个实例来说是不可配置的。

? Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。

校验：

? Struts 1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容，但不能校验子对象。

? Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验，来支持chain校验子属性

Action执行的控制：

? Struts1支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期。

? Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。