引用自：http://www.busfly.cn/csdn/post/587.html
1.Struts
struts框架具有組件的模塊化，靈活性和重用性的優點，同時簡化了基於MVC的web應用程序的開發。
優點：
Struts跟Tomcat、Turbine等諸多Apache項目一樣，是開源軟件，這是它的一大優點。使開發者能更深入的瞭解其內部實現機制。
除
此之外，Struts的優點主要集中體現在兩個方面：Taglib和頁面導航。Taglib是Struts的標記庫，靈活動用，能大大提高開發效率。另
外，就目前國內的JSP開發者而言，除了使用JSP自帶的常用標記外，很少開發自己的標記，或許Struts是一個很好的起點。
關於頁面導航，我認爲那將是今後的一個發展方向，事實上，這樣做，使系統的脈絡更加清晰。通過一個配置文件，即可把握整個系統各部分之間的聯繫，這對於後期的維護有着莫大的好處。尤其是當另一批開發者接手這個項目時，這種優勢體現得更加明顯。
另外，struts是業界"標準"（很多成功案例），學習資源豐富，HTML標籤非常優秀
缺點：
Taglib是Struts的一大優勢，但對於初學者而言，卻需要一個持續學習的過程，甚至還會打亂你網頁編寫的習慣，但是，當你習慣了它時，你會覺得它真的很棒。
Struts將MVC的Controller一分爲三，在獲得結構更加清晰的同時，也增加了系統的複雜度。
ActionForms使用不便、無法進行單元測試（StrutsTestCase只能用於集成）
2．Hibernate
Hibernate是一個開放源代碼的對象關係映射框架，它對JDBC進行了非常輕量級的對象封裝，使得Java程序員可以隨心所欲的使用對象編程思維來操縱數據庫。
Hibernate可以應用在任何使用JDBC的場合，既可以在Java的客戶端程序實用，也可以在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成數據持久化的重任。
大
多數開發機構經常採取創建各自獨立的數據持久層。一旦底層的數據結構發生改變，那麼修改應用的其餘部分使之適應這種改變的代價將是十分巨大的。
Hibernate適時的填補了這一空白，它爲Java應用提供了一個易用的、高效率的對象關係映射框架。hibernate是個輕量級的持久性框架，功
能卻非常豐富。
優點：
a.Hibernate 使用 Java 反射機制 而不是字節碼增強程序來實現透明性。
b.Hibernate 的性能非常好，因爲它是個輕量級框架。 映射的靈活性很出色。
c. 它支持各種關係數據庫，從一對一到多對多的各種複雜關係。
缺
點：它限制您所使用的對象模型。(例如，一個持久性類不能映射到多個表)其獨有的界面和可憐的市場份額也讓人不安，儘管如此，Hibernate
還是以其強大的發展動力減輕了這些風險。其他的開源持久性框架也有一些，不過都沒有 Hibernate 這樣有市場衝擊力。
3． Spring
它
是一個開源的項目，而且目前非常活躍；它基於IoC（Inversion of
Control，反向控制）和AOP的構架多層j2ee系統的框架，但它不強迫你必須在每一層
中必須使用Spring，因爲它模塊化的很好，允許你根據自己的需要選擇使用它的某一個模塊；它實現了很優雅的MVC，對不同的數據訪問技術提供了統一的
接口，採用IoC使得可以很容易的實現bean的裝配，提供了簡潔的AOP並據此實現Transcation Managment，等等
優點
a. Spring能有效地組織你的中間層對象，不管你是否選擇使用了EJB。如果你僅僅使用了Struts或其他爲J2EE的 API特製的framework，Spring致力於解決剩下的問題。
b. Spring能消除在許多工程中常見的對Singleton的過多使用。根據我的經驗，這是一個很大的問題，它降低了系統的可測試性和麪向對象的程度。
c.
通過一種在不同應用程序和項目間一致的方法來處理配置文件，Spring能消除各種各樣自定義格式的屬性文件的需要。曾經對某個類要尋找的是哪個魔法般的
屬性項或系統屬性感到不解，爲此不得不去讀Javadoc甚至源編碼？有了Spring，你僅僅需要看看類的JavaBean屬性。Inversion
of Control的使用（在下面討論）幫助完成了這種簡化。
d.通過把對接口編程而不是對類編程的代價幾乎減少到沒有，Spring能夠促進養成好的編程習慣。
e. Spring被設計爲讓使用它創建的應用儘可能少的依賴於他的APIs。在Spring應用中的大多數業務對象沒有依賴於Spring。
f. 使用Spring構建的應用程序易於單元測試。
g.Spring能使EJB的使用成爲一個實現選擇,而不是應用架構的必然選擇。你能選擇用POJOs或local EJBs來實現業務接口，卻不會影響調用代碼。
h. Spring幫助你解決許多問題而無需使用EJB。Spring能提供一種EJB的替換物，它們適用於許多web應用。
例如，Spring能使用AOP提供聲明性事務管理而不通過EJB容器，如果你僅僅需要與單個數據庫打交道，甚至不需要一個JTA實現。
i. Spring爲數據存取提供了一個一致的框架,不論是使用的是JDBC還是O/R mapping產品（如Hibernate）。
Spring確實使你能通過最簡單可行的解決辦法來解決你的問題。而這是有有很大價值的。
缺點：使用人數不多、jsp中要寫很多代碼、控制器過於靈活，缺少一個公用控制器
有關Hibernate優點和缺點的闡述
1.Hibernate優點：
（1）對象/關係數據庫映射(Basic O/R Mapping)
它使用時只需要操縱對象，使開發更對象化，拋棄了數據庫中心的思想，完全的面向對象思想。
（2）透明持久化(Persistent)
帶有持久化狀態的、具有業務功能的單線程對象，此對象生存期很短。這些對象可能是普通的JavaBeans/POJO，這個對象沒有實現第三方框架 或者接口，唯一特殊的是他們正與（僅僅一個）Session相關聯。一旦這個Session被關閉，這些對象就會脫離持久化狀態，這樣就可被應用程序的任 何層自由使用。（例如，用作跟表示層打交道的數據傳輸對象。）
（3）事務Transaction (org.Hibernate.Transaction)
應用程序用來指定原子操作單元範圍的對象，它是單線程的，生命週期很短。它通過抽象將應用從底層具體的JDBC、JTA以及CORBA事務隔離開。 某些情況下，一個Session之內可能包含多個Transaction對象。儘管是否使用該對象是可選的，但無論是使用底層的API還是使用 Transaction對象，事務邊界的開啓與關閉是必不可少的。
（4）它沒有侵入性，即所謂的輕量級框架。
（5）移植性會很好。
（6）緩存機制。提供一級緩存和二級緩存。
（7）簡潔的HQL編程。
2.Hibernate缺點：
（1）Hibernate在批量數據處理的時候是有弱勢。
（2）針對某一對象(單個對象)簡單的查/改/刪/增，不是批量修改、刪除，適合用Hibernate；而對於批量修改、刪除，不適合用Hibernate，這也是OR框架的弱點;要使用數據庫的特定優化機制的時候，不適合用Hibernate。
引用自：http://developer.51cto.com/art/200906/129451.htm
Hibernate 與 IBatis 的優缺點及可行性分析
1.優點
簡單：
易於學習，易於使用，通過文檔和源代碼，可以比較完全的掌握它的設計思路和實現。
實用：
提供了數據映射功能，提供了對底層數據訪問的封裝（例如ado.net），提供了dao框架，可以使我們更容易的開發和配置我們的dal層。
靈活：
通過sql基本上可以實現我們不使用數據訪問框架可以實現的所有功能，或許更多。
功能完整：
提供了連接管理，緩存支持，線程支持，（分佈式）事物管理，通過配置作關係對象映射等數據訪問層需要解決的問題。提供了dao支持，並在dao框架中封裝 了ado.net，Hibernate和datamapper.增強系統的可維護性：通過提供dal層，將業務邏輯和數據訪問邏輯分離，使系統的設計更清 晰，更易維護，更易單元測試 。sql和代碼的分離，提高了可維護性。
2.缺點
滯後性：
還沒有明確對。net2.0的支持。最新版本在2.0下編譯可以，但有些單元測試 不能通過。
不成熟，工程實踐較少：ibatisnet在實際項目中的使用較少。 只是理論上可行。
半orm，工具支持較少：需要我們自己寫sql，並且。net下還未發現可以自動生成業務層類和配置文件的工具，這點和Hibernate不一 樣，Hibernate會爲我們的數據庫直接產生sql，並有一些輔助工具。因此使用ibatis比Hibernate要多做一些工作。
3.可行性
沒有最好的框架，只有最適合的框架。 存在的便是合理的，它存在就說明有它存在的道理。但它未必爲我們存在。所以選擇一個框架最主要的是看它對你有沒有意義，意義有多大，是不是比其他框架帶給 你的好處要多。沒有絕對的優點也沒有絕對的缺點，重要的是看在什麼情況下討論。
上面說了部分的ibatis的優點和部分缺點。這些優點從理論上證明ibatis對任何數據持久層都合適，但未必是最好的選擇。下面對上面的優缺點分別從兩方面討論。
簡單：
我們都喜歡簡單，簡單意味着學習成本低，使用中出錯的可能性低。同時，簡單的東西一般來說功能不夠強大。反過來，複雜的東西學習成本高，用起來不方便，並且團隊沒有很強的技術實力，一般不要使用。
實用：
解決了項目中需要解決的問題，這是任何實際工程中採用的框架和工具都應具有的性質，否則就不要拿到實際項目中來。
靈活：
靈活有兩層意思，一種是簡單易擴展，另一種是功能強大提供了很多選項。ibatis屬於前者，Hibernate屬於後者。兩者各有優缺點。
功能完整：
ibatis的功能完整也是相對的，比我們自己開發的框架應該完整，但對比其他框架肯定也有一些解決不了的問題。
增強系統的可維護性：利用ibatis可以做到sql和代碼分離，可以設計出一個清晰的數據訪問層（dal）。但項目架構是否科學合理，是否以維護，關鍵 不在ibatis，因 爲它只是一個數據層框架。但是我們也不得不清楚，要想發揮ibatis的優勢，我們需要做一些額外工作，比如最好設計dao接口，需要將業務層實體和對實 體的訪問放在不同的工程中，同時需要維護xml配置文件。
滯後性：
ibatis組現在還沒有提到要支持。net2.0，很多人在。net2.0下使用ibatis都出現了問題。所以如果要使用。net2.0開發，ibatis不是一個好選擇，還需要等待。
不成熟：
開源的東西很難說成熟，但一般比我們自己寫的框架要成熟。由於我們可以拿到他的源代碼，所以關鍵在於我們能否駕馭它。
半orm，工具支持少：
這注定了ibatis不能從本質上提升開發效率，我們需要自己寫sql，寫實體類，寫配置文件。但這也是它優越的地方，它沒有爲我們做的他多，所以我們就 有更多的施展空間。而且它非常適合那些並不能完全控制數據庫的系統和需要利用數據庫本身提供的高級特性的統計查詢系統的開發。
使用ibatis需要自己寫sql，由於我們的sql不可能完全符合sql標準，比起Hibernate產生的sql來，可移植性差。不過由於我們更改 數據庫的可能性較小，對我們來說sql符合標準以便可以在遷移到不同服務器 時代價最小並不是十分必要的。另一方面，Hibernate雖然可以屏蔽很多 數據庫間的不同，但是卻很難利用某些數據庫的高級特性，比如oracle的分析統計函數。
Hibernate不適合數據庫模式不規範，約束不完整，需要大量複雜查詢的系統，同時Hibernate的學習成本較高，完全掌握Hibernate也較困難，風險較大。
自己寫框架未必比ibatis的好，穩定，強大和可擴展。而且自己開發框架也需要較大的工作量。
如果使用dotnet並且要選一個數據層框架，而系統中有相當一部分較複雜的sql，或數據庫設計不合理，髒數據多，對性能和資源要求嚴格，ibatis 是一個比較不錯的選擇。他的那些缺點並不是致命的，而且也是有一些解決方案的。尤其是，當選用了ibatis的dataaccess作爲dao框架時，我 們可以同時使用Hibernate，ado.net和datamapper（ibatisnet的核心組件），那樣將會使風險降到最低，並且整個系統的 框架比較合理。
另外，利用ibatis可以統一編碼風格，節約開發成本，大家不會再把精力浪費到分頁 連接池 主鍵生成等地方了，可以集中精力進行業務組件的編寫。
綜上： 很多時候我們要在是自己開發框架和選用第三方框架和選用什麼樣的框架問題上進行綜合考慮。考慮的標準當然是項目的當前情況和我們希望達到目的的一個平衡。
ibatis只是封裝了數據訪問層，替我們做了部分的對象關係映射。但我們的代價是必須要寫xml配置文件，相對於Hibernate我們還要寫很多 sql.Hibernate通過工具直接從數據庫模式生成實體類和基本的配置文件，而且大部分情況下不需要我們寫sql，會較大的提升開發效率。但這些也 有很多的侷限性，尤其是對環境的要求較高（數據庫設計，對象設計，團隊的協作等）。
個人感覺ibatis對項目比較有意義的地方在於它小巧靈活，可擴展，封裝了數據訪問層（事務，緩存，異常，日誌），並提供了dao框架支持。
利用ibatis我們可以做到代碼和sql的分離，只要sql能夠解決的問題，ibatis就能幫我們較容易的解決，同時也使我們的項目對某一框架的依賴 性變小（因爲ibatis是非侵入性的）。這將極大的降低項目風險，減少解決複雜問題的時間，使項目的維護變得簡單。
ibatis對於應用的修改，調試，擴充和維護將會變得容易自然。修改時，我們主要修改的是代表模型的實體對象，xml配置文件中的sql，和/或配置文 件的resultmap（很多時候是不需要的）。同時，sql和代碼分離，我們不用在代碼的stringbuffer的append方法之間尋找需要修改 的sql.配置文件中的sql便利了我們的調試和對sql的評審及以後的sql重用。
利用一些框架在前期一般會拖慢開發效率。因爲我們需要付出學習成本，很多時候，使用框架需要寫很多配置文件，在使用不熟時開發速度較慢；同時利用框架往往 使系統代碼量增大，比如model1和model2模型，開發效率應該還是model1快，四層的架構肯定比兩層的代碼量大。 但對於中後期開發和維護將會極大的提高效率。
利用一些較完全的開發框架和代碼生成工具，在前期會較大的提高開發效率，但在後期常常會拖慢進度，並有可能成爲以後維護的夢魘。比如torque生成實體類和其對應的sql，雖大幅提高了效率，但修改負擔較大。
比較理想的開發方式是使用簡單框架結合簡單的代碼生成工具。框架提供系統的基礎服務，並規範開發。框架一方面提供了開發中某一方面的開發基礎支持，比如數 據訪問層，事務，日誌，公用類，異常等。另一方面，也爲開發定義了模式，定義了系統的基本輪廓。同時，通過簡單的代碼生成工具生成部分低級的代碼。比如通 過工具從數據庫模式生成實體類。這些類生成後我們可以自由修改。
Hibernate是十分強大，比較完善的orm框架，不過這是它的優點也是它的缺點。 J2EE系統是否採用Hibernate3，是一個需要認真評估的問題。
要想Hibernate工作的好，數據庫的設計必須好。同時對於複雜的數據操作同時需要使用sql，Hibernate3對於直接使用sql的支持比Hibernate2要自然，這一點是可以接受的。
Hibernate比較複雜，功能強大而靈活，要用好Hibernate確實不是很簡單，當然spring框架提供了對Hibernate的封裝，使Hibernate的使用變得簡單了點。
可以說ibatis在任何系統裏都適用，但未必是最好選擇。不過ibatis提供的思路是我們應該仔細考慮的。
引用自：http://java.chinaitlab.com/Hibernate/787060.html