java 框架之間的比較

struts1與struts2本質區別 
1 在Action實現類方面的對比：Struts 1要求Action類繼續一個抽象基類；Struts 1的一個具體問題是使用抽象類編程而不是接口。Struts 2 Action類可以實現一個Action接口，也可以實現其他接口，使可選和定製的服務成爲可能。Struts 2提供一個ActionSupport基類去實現常用的接口。即使Action接口不是必須實現的，只有一個包含execute方法的POJO類都可以用 作Struts 2的Action。 
2 線程模式方面的對比：Struts 1 Action是單例模式並且必須是線程安全的，因爲僅有Action的一個實例來處理所有的請求。單例策略限制了Struts 1 Action能做的事，並且要在開發時非凡小心。Action資源必須是線程安全的或同步的；Struts 2 Action對象爲每一個請求產生一個實例，因此沒有線程安全問題。 
3 Servlet依靠方面的對比：Struts 1 Action依靠於Servlet API，因爲Struts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action不再依靠於Serzvlet API，從而答應Action脫離Web容器運行，從而降低了測試Action的難度。 當然，假如Action需要直接訪問HttpServletRequest和HttpServletResponse參數，Struts 2 Action仍然可以訪問它們。但是，大部分時候，Action都無需直接訪問HttpServetRequest和 HttpServletResponse，從而給開發者更多靈活的選擇。 
4 可測性方面的對比：測試Struts 1 Action的一個主要問題是execute方法依靠於Servlet API，這使得Action的測試要依靠於Web容器。爲了脫離Web容器測試Struts 1的Action，必須藉助於第三方擴展：Struts TestCase，該擴展下包含了系列的Mock對象（模擬了HttpServetRequest和HttpServletResponse對象），從而 可以脫離Web容器測試Struts 1的Action類。Struts 2 Action可以通過初始化、設置屬性、調用方法來測試。 
5 封裝請求參數的對比：Struts 1使用ActionForm對象封裝用戶的請求參數，所有的ActionForm必須繼續一個基類：ActionForm。普通的JavaBean不能用 作ActionForm，因此，開發者必須創建大量的ActionForm類封裝用戶請求參數。雖然Struts 1提供了動態ActionForm來簡化ActionForm的開發，但依然需要在配置文件中定義ActionForm；Struts 2直接使用Action屬性來封裝用戶請求屬性，避免了開發者需要大量開發ActionForm類的煩瑣，實際上，這些屬性還可以是包含子屬性的Rich 對象類型。假如開發者依然懷念Struts 1 ActionForm的模式，Struts 2提供了ModelDriven模式，可以讓開發者使用單獨的Model對象來封裝用戶請求參數，但該Model對象無需繼續任何Struts 2基類，是一個POJO，從而降低了代碼污染。 
6 表達式語言方面的對比：Struts 1整合了JSTL，因此可以使用JSTL表達式語言。這種表達式語言有基本對象圖遍歷，但在對集合和索引屬性的支持上則功能不強；Struts 2可以使用JSTL，但它整合了一種更強大和靈活的表達式語言：OGNL（Object Graph Notation Language），因此，Struts 2下的表達式語言功能更加強大。 
7 綁定值到視圖的對比：Struts 1使用標準JSP機制把對象綁定到視圖頁面；Struts 2使用“ValueStack”技術，使標籤庫能夠訪問值，而不需要把對象和視圖頁面綁定在一起。 
8 類型轉換的對比：Struts 1 ActionForm 屬性通常都是String類型。Struts 1使用Commons-Beanutils進行類型轉換，每個類一個轉換器，轉換器是不可配置的；Struts 2使用OGNL進行類型轉換，支持基本數據類型和常用對象之間的轉換。 
9 數據校驗的對比：Struts 1支持在ActionForm重寫validate方法中手動校驗，或者通過整合Commons alidator框架來完成數據校驗。Struts 2支持通過重寫validate方法進行校驗，也支持整合XWork校驗框架進行校驗。 
10 Action執行控制的對比：Struts 1支持每一個模塊對應一個請求處理（即生命週期的概念），但是模塊中的所有Action必須共享相同的生命週期。Struts 2支持通過攔截器堆棧（Interceptor Stacks）爲每一個Action創建不同的生命週期。開發者可以根據需要創建相應堆棧，從而和不同的Action一起使用。 
Hibernate優點 
(1) 對象/關係數據庫映射(ORM) 
它使用時只需要操縱對象，使開發更對象化，拋棄了數據庫中心的思想，完全的面向對象思想 
(2) 透明持久化(persistent) 
帶有持久化狀態的、具有業務功能的單線程對象，此對象生存期很短。這些對象可能是普通的JavaBeans/POJO，這個對象沒有實現第三方框架 或者接口，唯一特殊的是他們正與（僅僅一個）Session相關聯。一旦這個Session被關閉，這些對象就會脫離持久化狀態，這樣就可被應用程序的任 何層自由使用。（例如，用作跟表示層打交道的數據傳輸對象。） 
(3) 事務Transaction(org.hibernate.Transaction) 
應用程序用來指定原子操作單元範圍的對象，它是單線程的，生命週期很短。它通過抽象將應用從底層具體的JDBC、JTA以及CORBA事務隔離 開。某些情況下，一個Session之內可能包含多個Transaction對象。儘管是否使用該對象是可選的，但無論是使用底層的API還是使用 Transaction對象，事務邊界的開啓與關閉是必不可少的。 
(4) 它沒有侵入性，即所謂的輕量級框架 
(5) 移植性會很好 
(6) 緩存機制，提供一級緩存和二級緩存 
(7) 簡潔的HQL編程 
Hibernate缺點 
(1) Hibernate在批量數據處理時有弱勢 
(2) 針對單一對象簡單的增刪查改，適合於Hibernate,而對於批量的修改，刪除，不適合用Hibernate,這也是OR框架的弱點；要使用數據庫的特定優化機制的時候，不適合用Hibernate 
Hibernate和iBATIS 優缺點比較 
（注意:iBATIS 是MyBATIS的前生，也就是1.0版本） 
Hibernate的特點： 
Hibernate功能強大，數據庫無關性好，O/R映射能力強， Hibernate對數據庫結構提供了較爲完整的封裝，Hibernate的O/R Mapping實現了POJO 和數據庫表之間的映射，以及SQL 的自動生成和執行。程序員往往只需定義好了POJO 到數據庫表的映射關係，即可通過Hibernate 提供的方法完成持久層操作。程序員甚至不需要對SQL 的熟練掌握， Hibernate/OJB 會根據制定的存儲邏輯，自動生成對應的SQL 並調用JDBC 接口加以執行。Hibernate的缺點就是學習門檻不低，要精通門檻更高，而且怎麼設計O/R映射，在性能和對象模型之間如何權衡取得平衡，以及怎樣用 好Hibernate方面需要你的經驗和能力都很強才行，但是Hibernate現在已經是主流O/R Mapping框架，從文檔的豐富性，產品的完善性，版本的開發速度都要強於iBATIS。 
iBATIS的特點： 
iBATIS入門簡單， 即學即用，提供了數據庫查詢的自動對象綁定功能，而且延續了很好的SQL使用經驗，對於沒有那麼高的對象模型要求的項目來說，相當完美。iBATIS的缺 點就是框架還是比較簡陋，功能尚有缺失，雖然簡化了數據綁定代碼，但是整個底層數據庫查詢實際還是要自己寫的，工作量也比較大，而且不太容易適應快速數據 庫修改。當系統屬於二次開發,無法對數據庫結構做到控制和修改,那iBATIS的靈活性將比Hibernate更適合。系統數據處理量巨大，性能要求極爲 苛刻，這往往意味着我們必須通過經過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。在這種情況下iBATIS會有更好的可控性和表現。 
對於實際的開發進行的比較： 
1． iBATIS需要手寫sql語句，也可以生成一部分，Hibernate則基本上可以自動生成，偶爾會寫一些Hql。同樣的需求,iBATIS的工作量比 Hibernate要大很多。類似的，如果涉及到數據庫字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。 
2. iBatis 可以進行細粒度的優化 
比 如說我有一個表，這個表有幾個或者幾十個字段，我需要更新其中的一個字段，iBatis 很簡單，執行一個sql UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用 Hibernate 的話就比較麻煩了,缺省的情況下 hibernate 會更新所有字段。 當然我記得 hibernate 有一個選項可以控制只保存修改過的字段，但是我不太確定這個功能的負面效果。 
例 如：我需要列出一個表的部分內容，用 iBatis 的時候，這裏面的好處是可以少從數據庫讀很多數據，節省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE …一般情況下Hibernate 會把所有的字段都選出來。比 如說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我爲什麼要把他們也選出來呢？用 hibernate 的話，你又不能把這兩個不需要的字段設置爲lazy load，因爲還有很多地方需要一次把整個 domain object 加載出來。這個時候就能顯現出ibatis 的好處了。如果我需要更新一條記錄（一個對象），如果使用 hibernate，需要現把對象 select 出來，然後再做 update。這對數據庫來說就是兩條sql。而iBatis只需要一條update的sql就可以了。減少一次與數據庫的交互，對於性能的提升是非常重 要。 
3. 開發方面： 
開發效率上，我覺得兩者應該差不多。可維護性方面，我 覺得 iBatis 更好一些。因爲 iBatis 的 sql 都保存到單獨的文件中。而 Hibernate 在有些情況下可能會在 java 代碼中保sql/hql。相對Hibernate“O/R”而言，iBATIS 是一種“Sql Mapping”的ORM實現。（iBatis 是將sql寫在配置文件中的，而hibernate是自己生成的） 而iBATIS 的着力點，則在於POJO 與SQL之間的映射關係。也就是說，iBATIS並不會爲程序員在運行期自動生成SQL 執行。具體的SQL 需要程序員編寫，然後通過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定POJO。使用iBATIS 提供的ORM機制，對業務邏輯實現人員而言，面對的是純粹的Java對象，這一層與通過Hibernate 實現ORM 而言基本一致，而對於具體的數據操作，Hibernate會自動生成SQL 語句，而iBATIS 則要求開發者編寫具體的SQL 語句。相對Hibernate而言，iBATIS 以SQL開發的工作量和數據庫移植性上的讓步，爲系統設計提供了更大的自由空間。 
4. 運行效率 
在不考慮 cache 的情況下，iBatis 應該會比hibernate 快一些或者很多。 
Spring 框架的優缺點 
Spring的優勢不言而喻： 
　 1. 提供了一種管理對象的方法，可以把中間層對象有效地組織起來。一個完美的框架“黏合劑”。 
　 2. 採用了分層結構，可以增量引入到項目中。 
　 3. 有利於面向接口編程習慣的養成。 
　 4. 目的之一是爲了寫出易於測試的代碼。 
　 5. 非侵入性，應用程序對Spring API的依賴可以減至最小限度。 
　 6. 一致的數據訪問介面。 
　 6. 一個輕量級的架構解決方案 
缺點也顯而易見 
1. 中斷了應用程序的邏輯，使代碼變得不完整，不直觀。此時單從Source無法完全把握應用的所有行爲。 
　2. 將原本應該代碼化的邏輯配置化，增加了出錯的機會以及額外的負擔。 
3. 時光倒退，失去了IDE的支持。在目前IDE功能日益強大的時代，以往代碼重構等讓人頭痛的舉動越來越容易。而且IDE還提供了諸多強大的輔助功能，使得 編程的門檻降低很多。通常來說，維護代碼要比維護配置文件，或者配置文件+代碼的混合體要容易的多。 
　4. 調試階段不直觀，後期的bug對應階段，不容易判斷問題所在。 
經典架構S（Struts）SH的優缺點 
Struts、Spring、Hibernate能流行這麼多年經久不衰，自然有它的道理。J2EE最先出現的時候，我們一般是採用 JSP+Servlet+JavaBean+EJB的架構，尤其是1998年～2000年這段時間，互聯網的泡沫從興起到破裂，其波瀾壯闊程度，絲毫不亞 於2008年開始的這次經濟危機，在那個年代，是否掌握EJB開發技術將直接決定你的薪水能否翻一倍或者幾倍。不過，Spring的作者Rod Johnson在2002年根據多年經驗撰寫了《Expert o-ne-on-One J2EE Design and Development》，其後又發表了著名的《Expert o-ne-on-one J2EE Development without EJB》一書，則徹底地改變了傳統的J2EE一統天下的開發架構，基於Struts+Hibernate+Spring的J2EE架構也逐漸得到人們的認 可，甚至在大型的項目架構中也逐漸開始應用。下面我們分別說說Spring、Struts和Hibernate的優缺點。 
Spring 是一個開源框架，是爲了解決企業應用程序開發複雜性而創建的。框架的主要優勢之一就是其分層架構，使得每個層之間和類與類之間的關係，由原來的強綁定與強 耦合轉變爲不綁定和鬆耦合，直接面向接口編程，把設計與實現相分離的原則發揮到極致，對於單元測試也產生了很深遠的影響。在Spring出現之前，如果某 個模塊沒有完成，做單獨模塊的單元測試還是很困難的。Spring同時也是 J2EE 應用程序開發的集成框架，因爲J2EE是講究分層理念的，Spring使得J2EE每個層之間的模塊職能更加清晰。 
不過，對於大型項目的開發，Spring使得原來難以維護的類與類之間的強耦合關係，轉變爲更加難以維護的XML文件配置，這個工作量也是非常巨大 的，而且更容易出錯。而且，隨着每個應用 模塊的升級，這些模塊之間的版本，也不會是同步更新的，對於同一個公共組件，有的模塊用的可能是1.0版本，而另 外一個功能模塊用的可能是2.0版本，可怕的是1.0版本和2.0版本之間，可能還不兼容，Spring對於這些需求，就無能爲力了。所以，有人說 Spring不適合大型項目開發，也是有一定道理的。最近Spring也加入了OSGI標準的實現，也是爲了解決不同版本之間同時存在的這些問題。不過， 隨着Spring加入的功能越來越多，Spring也就失去了輕量開源框架的特點，變得越來越笨重。 
雖然Spring現在也支持了所謂的免配置，可以通過@Autowired標籤自行綁定，還可以通過 設置自動綁定加載所有的Hibernate對象，但是如果這些上百個或者數十個中的任何一個Entity對象加載失敗，則整個Spring服務就啓動不起 來了，這與難於部署的EJB有啥區別呢？而且，令人可笑的是，由於使用了@Autowired標籤，相當一部分開發人員不再面向接口編程了，對於 Class A的實例，美其名曰由Spring自行綁定，接口也好，實際實現類也好，就在Spring配置一下就可以了。而Spring最核心的就是面向接口編程和 IOC，沒有了面向接口編程，用一個 A a=new A() 來實例化一個Class，有什麼不可以呢？少寫了一行代碼，引入了一個重量級的Spring，究竟爲啥使用Spring呢？ 
對於Hibernate的流行，則是由於開發人員和客戶，對於Entity EJB（實體EJB）臃腫的身材及部署的困難，是在極度失望情緒下造成的。既然是輕量級解決方案，那麼分佈式就不是可選項，沒有分佈式，那麼EJB就無用 武之地了。話又說回來了，Rod Johnson前些年就因爲強調絕大部分企業應用是不需要分佈式的，從而推出了自己輕量級的Spring解決方案。但是最近一年，隨着雲計算架構的興起， 架構是否支持分佈式，又是必選項了。技術架構的選型，就跟法國巴黎流行時裝一樣，今年流行短袖，明年流行下襬，真是典型的十年河東，十年河西。所以，像 SOA、雲計算、SaaS、物聯網這些大名詞，不僅會給客戶帶來很大的困惑，同樣也會給程序員、系統分析師、系統架構師、技術總監帶來困惑。從肯定到否 定，再到自我否定，真是符合大自然螺旋式上升的發展規律。 
而對於Struts，它一經推出，幾乎打敗了當時的所有競爭對手。Struts的偉大之處，在於它對網頁數據的動態綁定。雖然數據綁定不是一個新名 詞，微軟在1991年推出Visual Basic1.0的時候，就創造性地發明了讓VB程序員又愛又恨的數據綁定，但是對於Web 編程，Struts也還是把數據綁定首次應用到了Web編程上。它能夠讓人們用Set和Get的形式取得網頁數據，而不是單一的黑盒式的 request.getParameter()，從而使得網頁數據取值進入面向對象（OO）化時代。 
Struts、Hibernate以及Spring本身都是製作精良的框架，但是對於自己產品和項目的應用，一經整合在一起，卻不一定很適用。比如 說，對於數據庫相關的MIS（管理信息系統）系統中，增加、修改、刪除、查詢功能是最基本、最常見、必不可少的。對於這些最基本的功能，不同的架構師，則 會做出不同的選擇。有的架構師，選擇了自動生成的理念，做一個代碼自動生成器，設計好數據庫表結構，單擊一個腳本，或者用Eclipse插件的形式，做個 圖形化生成界面，自動生成SSH框架，完成數據庫的增加、修改、刪除、查詢操作。這麼做的好處是數據庫修改了，代碼自動生成就可以了，使得程序員不用再維 護這些無聊的代碼。不過缺陷也是致命的，一是隨着Struts、Hibernate、Spring的升級，這個工具也不得不跟着升級，而做這個工具的程序 員，可能早就離開公司了，後續版本無法維護；二是如果有的業務邏輯跟這些生成的代碼有交叉，數據庫變更後，代碼也無法再次生成了。三是公司的系統架構，則 被嚴重限制在SSH架構基礎上，再也無法改變。有人會問：即使限制在這三種架構上，有何不好嗎？假設有客戶問，你的框架支持雲計算嗎？你總不能說”由於 Struts、Hibernate、Spring 不支持雲計算架構，所以我也不支持”以此取得客戶諒解吧。因此，依賴於第三方架構的產品體系架構，隨着時間的推移，受到的限制會越來越大。