項目也做過幾個, 使用IBatis就做一個項目, 基本上都是使用Hibernate, 也只是知道幾點關於這兩個框架的區別, 今天閒着沒事幹, 從網上找了幾篇文章, 做了一個簡單的整理。網上關於這兩個框架的比較也很多, 只是自己想把別人的東西拿過來整理一下, IBatis和Hibernate的比較。(非原創)
Hibernate VS iBATIS
簡介Hibernate是當前最流行的O/R mapping框架，當前版本是3.05。它出身於sf.net，現在已經成爲Jboss的一部分了。
iBATIS是另外一種優秀的O/R mapping框架，當前版本是2.0。目前屬於apache的一個子項目了。
相對Hibernate"O/R"而言，iBATIS 是一種"Sql Mapping"的ORM實現。
Hibernate對數據庫結構提供了較爲完整的封裝，Hibernate的O/R Mapping實現了POJO和數據庫表之間的映射，以及SQL的自動生成和執行。程序員往往只需定義好了POJO到數據庫表的映射關係，即可通過Hibernate提供的方法完成持久層操作。程序員甚至不需要對SQL的熟練掌握，Hibernate/OJB會根據制定的存儲邏輯，自動生成對應的SQL並調用JDBC接口加以執行。
而iBATIS的着力點，則在於POJO與SQL之間的映射關係。也就是說，iBATIS並不會爲程序員在運行期自動生成SQL執行。具體的SQL需要程序員編寫，然後通過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定POJO。使用iBATIS提供的ORM機制，對業務邏輯實現人員而言，面對的是純粹的Java對象，這一層與通過Hibernate 實現ORM而言基本一致，而對於具體的數據操作，Hibernate會自動生成SQL語句，而iBATIS則要求開發者編寫具體的SQL語句。相對Hibernate而言，iBATIS以SQL開發的工作量和數據庫移植性上的讓步，爲系統設計提供了更大的自由空間。
二者的對比：
1． iBATIS非常簡單易學，Hibernate相對較複雜，門檻較高。
2． 二者都是比較優秀的開源產品。
3． 當系統屬於二次開發,無法對數據庫結構做到控制和修改,那iBATIS的靈活性將比Hibernate更適合。
4． 系統數據處理量巨大，性能要求極爲苛刻，這往往意味着我們必須通過經過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。在這種情況下iBATIS會有更好的可控性和表現。
5． iBATIS需要手寫sql語句，也可以生成一部分，Hibernate則基本上可以自動生成，偶爾會寫一些Hql。同樣的需求,iBATIS的工作量比Hibernate要大很多。類似的，如果涉及到數據庫字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。
6． 以數據庫字段一一對應映射得到的PO和Hibernte這種對象化映射得到的PO是截然不同的，本質區別在於這種PO是扁平化的，不像Hibernate映射的PO是可以表達立體的對象繼承，聚合等等關係的，這將會直接影響到你的整個軟件系統的設計思路。
7． Hibernate現在已經是主流O/R Mapping框架，從文檔的豐富性，產品的完善性，版本的開發速度都要強於iBATIS。
8． 最關鍵的一句話是iBATIS的作者說的：
If you are starting a new project and you're in full control of your object model and database design, Hibernate is a good choice of O/R tool.
If you are accessing any 3rd party databases (e.g. vendor supplied), or you're working with a legacy database, or even just a really poorly designed database, then an O/R mapper might not be capable of handling the situation. That's were an SQL Mapper comes in handy
結論:
Hibernate和iBATIS可以說是互相補充,共同發展的關係.具體你想用什麼要看實際情況.如果看了上面的文字還是拿不定注意,那就Just to try it.實踐是檢驗真理的唯一標準.鞋合不合適,只有試了才知道。
說明：本文轉自：http://blog.csdn.net/hero272285642/archive/2008/04/25/2327887.aspx
選擇Hibernate還是iBATIS都有它的道理：
Hibernate功能強大，數據庫無關性好，O/R映射能力強，如果你對Hibernate相當精通，而且對Hibernate進行了適當的封裝，那麼你的項目整個持久層代碼會相當簡單，需要寫的代碼很少，開發速度很快，非常爽。
Hibernate的缺點就是學習門檻不低，要精通門檻更高，而且怎麼設計O/R映射，在性能和對象模型之間如何權衡取得平衡，以及怎樣用好Hibernate方面需要你的經驗和能力都很強才行。
iBATIS入門簡單，即學即用，提供了數據庫查詢的自動對象綁定功能，而且延續了很好的SQL使用經驗，對於沒有那麼高的對象模型要求的項目來說，相當完美。
iBATIS的缺點就是框架還是比較簡陋，功能尚有缺失，雖然簡化了數據綁定代碼，但是整個底層數據庫查詢實際還是要自己寫的，工作量也比較大，而且不太容易適應快速數據庫修改。
我的建議就是：
如果你的團隊沒有Hibernate高手，那麼請用iBATIS，要把Hibernate用好，並不容易；否則你應該選擇Hibernate，那樣你的開發速度和代碼簡潔性都相當棒！
我覺得rails的ActiveRecord是平衡性做的最好的，避免了Hibernate的複雜性和學習HQL的成本，同時具備iBATIS即學即用的簡單性。
說明：本文轉自：http://robbin.javaeye.com/blog/24529
我爲什麼選擇 iBatis而不是 Hibernate(對於正在選型的人的建議)
1. iBatis易於掌握。拿來文檔看半天到兩天就可以掌握了。
Hibernate可能需要3倍以上的時間來掌握。
2. iBatis更容易進行sql的優化。
這個應該大家都有共識了。另外Hibernate生成的sql也實在是太難看了。鑑於有的朋友提到了sql不太重要。我想在這裏強調一下我的經驗，一般系統性能的瓶頸都在數據庫上。所以這一點是iBatis非常重要的一個優勢。
3. iBatis 可以進行細粒度的優化
3.1 比如說我有一個表，這個表有幾個或者幾十個字段，我需要更新其中的一個字段，iBatis很簡單，執行一個sql：UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用Hibernate的話就比較麻煩了,缺省的情況下hibernate會更新所有字段。當然我記得hibernate有一個選項可以控制只保存修改過的字段，但是我不太確定這個功能的負面效果。
3.2 我需要列出一個表的部分內容，用iBatis的時候，這裏面的好處是可以少從數據庫讀很多數據，節省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...
3.2.1 一般情況下Hibernate會把所有的字段都選出來。比如說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我爲什麼要把他們也選出來呢？
3.2.2 用hibernate的話，你又不能把這兩個不需要的字段設置爲lazy load，因爲還有很多地方需要一次把整個 domain object 加載出來。這個時候就能顯出ibatis的好處了
3.2.3 Hibernate還有一個方案，就是生成javabean/map/object[](感謝leelun/cjmm)，但是這樣的話就可能會產生大量的多餘class。map/object[] 的方式應該不錯，我比較喜歡這種方式。
3.3 如果我需要更新一條記錄（一個對象），如果使用hibernate，需要現把對象select出來，然後再做update。這對數據庫來說就是兩條sql。而iBatis只需要一條update的sql就可以了。減少一次與數據庫的交互，對於性能的提升是非常重要。
4. 開發方面
4.1 開發效率上，我覺得兩者應該差不多
4.2 可維護性方面，我覺得iBatis更好一些。因爲iBatis的sql都保存到單獨的文件中。而Hibernate在有些情況下可能會在java代碼中保存sql/hql。
5. 運行效率
5.1 在不考慮cache的情況下，iBatis應該會比hibernate快一些或者很多（根據實際情況會有所不同）。
當然iBatis也有比較大的缺點
1. 不同數據庫類型的支持不好，如果你要開發的系統是要在對中數據間移植，那可能用hibernate比較好。
2. 缺省的cache支持不好，但是hibernate的cache支持其實也不是很好，而且很複雜。尤其是對於大併發量的應用。所以我更傾向於自己管理cache。
hibernate與ibatis比較的11大優勢
Hibernate在解決性能問題方面做得非常好。有了它的緩存機制，使用第三方緩存和數據庫連接池，就較好的解決的性能問題。但這些還不夠，hibernate給了開發者足夠的自由，讓開發者自己去控制性能問題。
學習了一段時間的ibatis，我覺得hibernate有着ibatis無法替代的優勢。
1、開發者都知道，hibernate讓我們以oo的方式操作數據庫，這讓我們看到了hibernate的強大之處，體驗到操作數據的方便。但Gavin King說，hibernate最耀眼之處是hibernate的緩存機制，而不是以oo的方式操作數據庫。Hibernate的緩存機制不外乎是一級緩存session，二級緩存sessionFactory，和第三方緩存如ehcache。也就是hibernate的最強大的地方是它的緩存，理解了這個才能真正的理解hibernate。緩存實在太難了，我至今未能真正理解。
2、可維護性：ibatis宣揚寫sql語句，它將sql語句放進一個單獨的xml文件，這種方式贏得了很多開發者的喜愛，一句話，方便維護。但hibernate同樣具有這種功能，而且比ibatis更加強大。Hibernate的命名查詢/命名參數查詢，就是將hql語句放在一個單獨的xml文件之中，它仍然讓人們以面向對象的方式去操縱數據，這得到大量遵循 oo方式開發者的喜愛，而不用在以oo的方式寫着代碼的同時，然後再轉變思維，用面向關係的方式去寫那些sql語句。但hibernate不僅做了這些， 它的native sql查詢方式，完全滿足sql語句的偏愛者，它像ibatis一樣，將sql語句放在配置文件之中。
3、性能：我堅信，hibernate性能問題不是問題。想想那麼多大中小項目都在使用hibernate，你還懷疑hibernate的性能嗎？spring整合hibernate之後，在真正性能瓶頸的地方，完全可以使用spring集成的jdbc，或直接寫存儲過程得了。但首先得確認，這實在是性能瓶頸的地方，我想，不應想當然的認爲性能的問題，所謂的性能問題阻撓了很多人。我認爲，性能的好壞無外是發送sql語句的多少而已。性能好，發送的sql語句少，性能差，就是發送大量的sql語句。Hibernate在解決性能問題方面做得非常好。有了它的緩存機制，使用第三方緩存和數據庫連接池，就較好的解決的性能問題。但這些還不夠，hibernate給了開發者足夠的自由，讓開發者自己去控制性能問題。
我認爲開發者可以在以下幾個方面自行調優：
a、在查詢字符串中，應該總是使用jdbc的佔位符？，或使用使用命名參數：，不要自查詢中使用字符串值來代替非常量值。
b、Flush會影響性能，頻繁刷新影響性能，儘量減少不必要的刷新。
c、Cascade策略，在幾對幾的關係，正確設置cascade策略，想清楚在操作對象A的同時是否需要級聯操作對象B，比如在one to many的父子關係中，刪除了父親one，需級聯刪除子many，這時的one這端可設置cascade="delete"，這樣在刪除one時，會自動刪除子，但對子的操作不會影響父。Cascade還有其他的屬性值，只要設置正確，可提升性能。
d、lazy策略，正確設置延遲加載策略同樣會提升性能，在one to many或many to many中，通常總應該延遲加載many的一方的到內存。設置了lazy="true"，首先發送sql語句，加載自己到內存，到需要時才加載級聯對象；lazy="false",則會同時加載自己和級聯對象到內存。
e、另外還有集合的性能(set、list、map、array)，都應正確設置。
f、正確使用第三方緩存，在讀操作頻繁寫操作不多的情況，使用第三方緩存可大幅度提升性能，如ehcache的緩存策略有：read-only，read-write和notstrict-read-write。
f、 隨着hibernate新版本的發佈，和技術的發展，我相信hibernate的性能會越來越好，所有性能不是不使用hibernate的原因。
4、hibernate不僅僅作爲持久層的orm框架存在，它除了dao層的持久化操作外，還有很多。
在註解annotation已經走向主流的今天，hibernate 迅速響應，讓xml部署描述符成爲可選的。Hibernate annotation對大字段的處理只是一個@Lob就搞定了。
hibernate search對Lucene進行了輕量級的封裝，全文檢索變得非常簡單。
Hibernate validator被認爲是最合理的驗證方式，將驗證策略直接附在貫穿各層的領域模型domain上，不再需要哪些web框架的xml方式的驗證，代碼中不再出現大量的非空/null的判斷。
5、jbpm，Jbpm業務流程引擎的持久層採用hibenrnate來實現，要想使用jbpm，hibernate是必須的。我想，業務流程管理無比重要，在SOA迅速發展的今天，如果實施SOA項目，業務流程管理是必然和必須的。因爲soa就是業務和it技術的融合，是業務流程管理和it基礎架構的融合。在soa中，業務管理是第一位的，這需要相應的技術來實現該業務流程管理。開源領域的jbpm我想會是首選。所以，爲了將來有可能實施soa項目，爲了實現soa的業務流程管理，應該使用hibernate。
6、大家都知道，hibernate將ejb2時代的實體bean趕進了歷史，而ejb3的jpa標準也只不過是hibernate的子集而已。jsr規範請求的威力是巨大的，沒有各種jsr規範請求，就不會有各種應用程序框架，各種應用程序框架只是那些jsr規範請求的實現者。jpa作爲持久層的規範標準，引導持久層orm框架的方向，jpa同樣以面向對象的方式操作數據庫，而不是寫sql語句。規範標準都完全orm，不寫sql了，你還有理由不跟着它嗎？
7、Spring+hibernate+範型+可變參數，這是一個非常強大的組合，對應普通的crud操作，你不再需要重複寫那些煩人的相似的dao層和manager層的代碼，僅僅需要寫一次，就完成了所有大量的crud操作。Ibatis儘管也支持範型，但始終沒有hibernate支持的好
8、Jboss，hibernate是jboss的項目，jboss的所有項目的持久層都採用的hibernate，要知道，jsr規範組的專家們大多數是來自jboss的，在一定程度上說，jboo引領着java的發展方向。使用hibernate，跟着jboss，不偏離java的發展方向。
9、Gavin King，我最崇拜的偶像，他不僅發明了強大的hibernate，還搞出了同樣強大且優雅的web2.0應用程序框架seam。他是ejb3.0專家組成員之一，是jpa規範請求的領導者，他java領域最有發言權、最權威的領袖人物之一。現在，他領導web bean的，jsr299的發展，web bean規範的制定，全球軟件巨頭如ibm、oracle、bea和apache沒有一個反對，紛紛響應。Web bean，想象起來，實在太美好了，完全的鬆耦合和強類型，所有的應用組件生活在一個應用組件上下文context中，相互合作。那時將不再有各種各樣的上下文環境，不再有struts2的ActionContext，不再有spring的ApplicationContext，不再有hibernate
的session，不再有持久化上下文，不再有事務上下文，不再有安全上下文，所有組件生活在一個大家庭中，大家其樂融融，實現天下的大和平。
10、 osgi，我認爲現在最值得學習的一個技術，有了osgi，實現真正的多模塊開發，改變傳統的開發方式。現在，已經有了hibernate osgi，spring dynamic modul(osgi),struts 2同樣實現了對osgi的支持。目前，eclipse是基於osgi開發的，ibm的websphere v6.1，bea的所有產品都重構在osgi上，spring的應用服務器同樣基於osgi，在EclipseCon2007上，osgi成爲了主要的話題。Osgi受到如此的待遇，一點不奇怪，因爲他具有無比強大的功能，改變傳統的軟件開發方式。Osgi採用樹設計模式，將一個項目分成多個模塊(bundle)，每個模塊單獨部署，單獨運行，說白了，就是將一個工程分成許多的插件，每個插件單獨開發，重複使用，實現完全的即插即用。太令人激動了。如果公司的軟件開發基於osgi，將會有大量的重複使用的osgi
bundles，公司將會積累大量的無形資產，軟件開發將會越來越快。而ibatis現在還沒見到對osgi的支持。
11、hibernate的社區非常繁榮，ibatis則相對平靜。
綜述，hibernate還有很多優秀的特點，只是我們不知道。Hibernate與ibatis，就像大家閨秀對小家碧玉，大家閨秀不僅具有小家碧玉的全部，而且知名度更高，更受尊敬，更受人追捧，更有發展前途。小家碧玉儘管也很有魅力，但始終比上大家閨秀。
Hibernate所做的不僅僅是dao層的持久化工作，而ibatis恰恰如此。
選擇hibernate，選擇orm的王者，選擇更全面的工作體驗，選擇更高效的工作方式，選擇更多的利潤；選擇Gavin King，跟着領袖走；選擇jboss，追隨開源的潮流，不偏離java的發展方向。
一切都不是藉口。一切都在發展，hibernate會越來越好。
本文來自:http://blog.sina.com.cn/s/blog_4adc4b0901010kcx.html
Hibernate與IBatis的優缺點及可行性分析
簡單：
易於學習，易於使用，通過文檔和源代碼，可以比較完全的掌握它的設計思路和實現。
實用：
提供了數據映射功能，提供了對底層數據訪問的封裝（例如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提供的思路是我們應該仔細考慮的。