Struts1和Struts2的區別和對比:

Apache Struts（簡稱Struts）是一種非常流行的Web框架，可用于使用java企業版（JEE）開發Web應用。Struts項目是負責開發及維護 Struts框架的開源社區。Struts在2001年7月發布，目前已成為使用JEE開發Web應用的事實上的標準。而社區新近發布的Struts 2.0更是一種精致、可擴展的框架，可用于使用Java代碼來開發企業就緒的Web應用。該框架旨在簡化從構建、部署到日常維護的整個應用開發周期。

設計Struts框架的目的是為了讓開發人員可以構建一種數據庫代碼、頁面設計代碼和控制流程代碼不混合在一起的服務器小程序或者JavaServer Pages。因為，要是代碼混合在一起，隨著應用越來越龐大，就會變得難以維護。Struts框架基于MVC架構，可以幫助開發人員利用明確的關注點分離（separation of concerns）原則，開發動態Web應用。

Struts 2請求處理流程這個架構實際上又是如何工作的呢？初始請求先發送到服務器小程序容器（譬如Tomcat），然后通過一系列過濾器傳送。如果與Site Mesh插件等其他技術集成，可選的ActionContextCleanUp過濾器就很有用，要是用到這個過濾器，請求先通過它傳送。

接著，調用請求的FilterDispatcher，它使用ActionMapper來確定要不要為這個請求調用動作。如果ActionMapper確定應當調用Action，FilterDispatcher就把控制權委托給ActionPRoxy。

ActionProxy使用了框架配置文件管理器，該管理器通過struts.xml文件來初始化。然后，ActionProxy創建ActionInvocation，它負責實現命令模式。ActionInvocation進程調用所需的攔截器，然后調用Action。一旦該Action執行，ActionInvocation 就負責查尋與struts.xml中映射的Action結果代碼相關的合理結果。

然后結果被執行，大多數時候，這會顯示用FreeMarker或者Velocity編寫的jsp或者模板。按照相反順序完成Action之后，攔截器再次得到執行。最后，響應通過web.xml中配置的過濾器返回。如果ActionContextCleanUp過濾器經過配置，FilterDispatcher就不會清理ThreadLocal ActionContext（ActionContext擁有運行時請求和響應的全部細節，該框架使用ThreadLocal以及 ActionContext類來提供配置及其他運行時細節）。如果ActionContextCleanUp過濾器未經配置，FilterDispatcher就會清理所有的當前ThreadLocal。圖1描述了Struts 2框架的架構。

FilterDispatcher，將接收所有請求，并根據ActionMapper（請參考：docs/actionmapper.html）所提供的 信息，決定Action是否應該被調用或哪些方法將被調用（如判斷其URL擴展名是否符合要求，URL是否符合某些特定的語法規則（如 foo!bar.action將調用foo類的bar方法）等，請參考相關的文檔），當然，對于ActionMapper而言，由于它的判斷需要依賴于 struts2的配置，所以，它也要用到 ConfigurationManager來獲得配置信息。接下來，針對每個Action類，將創建ActionProxy對象，它的創建依賴于ConfigurationManager（即配置文件）。接下來執行ActionProxy對象的execute方法，如果給Action配置了一系列攔截器，那么這個Action的代理類將逐個執行這些攔截器。當ActionProxy調用Action的方法，執行完之后，它將獲得相關的Result對象，并調用Result.的execute方法來產生response對象。

Action 類: • Struts1要求Action類繼承一個抽象基類。Struts1的一個普遍問題是使用抽象類編程而不是接口，而struts2的Action是接口。 • 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一起使用。