原文地址：http://blog.csdn.net/ya2dan/article/details/7396598

?

項目也做過幾個, 使用IBatis就做一個項目, 基本上都是使用Hibernate, 也只是知道幾點關(guān)于這兩個框架的區(qū)別, 今天閑著沒事干, 從網(wǎng)上找了幾篇文章, 做了一個簡單的整理。網(wǎng)上關(guān)于這兩個框架的比較也很多, 只是自己想把別人的東西拿過來整理一下, IBatis和Hibernate的比較。(非原創(chuàng))

Hibernate ?VS ?iBATIS

簡介
Hibernate是當(dāng)前最流行的O/R mapping框架，當(dāng)前版本是3.05。它出身于sf.net，現(xiàn)在已經(jīng)成為Jboss的一部分了。
iBATIS是另外一種優(yōu)秀的O/R mapping框架，當(dāng)前版本是2.0。目前屬于apache的一個子項目了。
相對Hibernate"O/R"而言，iBATIS 是一種"Sql Mapping"的ORM實現(xiàn)。
Hibernate對數(shù)據(jù)庫結(jié)構(gòu)提供了較為完整的封裝，Hibernate的O/R Mapping實現(xiàn)了POJO和數(shù)據(jù)庫表之間的映射，以及SQL的自動生成和執(zhí)行。程序員往往只需定義好了POJO到數(shù)據(jù)庫表的映射關(guān)系，即可通過Hibernate提供的方法完成持久層操作。程序員甚至不需要對SQL的熟練掌握，Hibernate/OJB會根據(jù)制定的存儲邏輯，自動生成對應(yīng)的SQL并調(diào)用JDBC接口加以執(zhí)行。
而iBATIS的著力點，則在于POJO與SQL之間的映射關(guān)系。也就是說，iBATIS并不會為程序員在運行期自動生成SQL執(zhí)行。具體的SQL需要程序員編寫，然后通過映射配置文件，將SQL所需的參數(shù)，以及返回的結(jié)果字段映射到指定POJO。使用iBATIS提供的ORM機制，對業(yè)務(wù)邏輯實現(xiàn)人員而言，面對的是純粹的Java對象，這一層與通過Hibernate 實現(xiàn)ORM而言基本一致，而對于具體的數(shù)據(jù)操作，Hibernate會自動生成SQL語句，而iBATIS則要求開發(fā)者編寫具體的SQL語句。相對Hibernate而言，iBATIS以SQL開發(fā)的工作量和數(shù)據(jù)庫移植性上的讓步，為系統(tǒng)設(shè)計提供了更大的自由空間。
二者的對比：
1． ?iBATIS非常簡單易學(xué)，Hibernate相對較復(fù)雜，門檻較高。
2． ?二者都是比較優(yōu)秀的開源產(chǎn)品。
3． ?當(dāng)系統(tǒng)屬于二次開發(fā),無法對數(shù)據(jù)庫結(jié)構(gòu)做到控制和修改,那iBATIS的靈活性將比Hibernate更適合。
4． ?系統(tǒng)數(shù)據(jù)處理量巨大，性能要求極為苛刻，這往往意味著我們必須通過經(jīng)過高度優(yōu)化的SQL語句（或存儲過程）才能達到系統(tǒng)性能設(shè)計指標(biāo)。在這種情況下iBATIS會有更好的可控性和表現(xiàn)。
5． ?iBATIS需要手寫sql語句，也可以生成一部分，Hibernate則基本上可以自動生成，偶爾會寫一些Hql。同樣的需求,iBATIS的工作量比Hibernate要大很多。類似的，如果涉及到數(shù)據(jù)庫字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。
6． ?以數(shù)據(jù)庫字段一一對應(yīng)映射得到的PO和Hibernte這種對象化映射得到的PO是截然不同的，本質(zhì)區(qū)別在于這種PO是扁平化的，不像Hibernate映射的PO是可以表達立體的對象繼承，聚合等等關(guān)系的，這將會直接影響到你的整個軟件系統(tǒng)的設(shè)計思路。
7． ?Hibernate現(xiàn)在已經(jīng)是主流O/R Mapping框架，從文檔的豐富性，產(chǎn)品的完善性，版本的開發(fā)速度都要強于iBATIS。
8． ?最關(guān)鍵的一句話是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

結(jié)論:
Hibernate和iBATIS可以說是互相補充,共同發(fā)展的關(guān)系.具體你想用什么要看實際情況.如果看了上面的文字還是拿不定注意,那就Just to try it.實踐是檢驗真理的唯一標(biāo)準(zhǔn).鞋合不合適,只有試了才知道。

說明：本文轉(zhuǎn)自：http://blog.csdn.net/hero272285642/archive/2008/04/25/2327887.aspx

?

選擇Hibernate還是iBatis?
選擇Hibernate還是iBATIS都有它的道理：?
Hibernate功能強大，數(shù)據(jù)庫無關(guān)性好，O/R映射能力強，如果你對Hibernate相當(dāng)精通，而且對Hibernate進行了適當(dāng)?shù)姆庋b，那么你的項目整個持久層代碼會相當(dāng)簡單，需要寫的代碼很少，開發(fā)速度很快，非常爽。?
Hibernate的缺點就是學(xué)習(xí)門檻不低，要精通門檻更高，而且怎么設(shè)計O/R映射，在性能和對象模型之間如何權(quán)衡取得平衡，以及怎樣用好Hibernate方面需要你的經(jīng)驗和能力都很強才行。?
iBATIS入門簡單，即學(xué)即用，提供了數(shù)據(jù)庫查詢的自動對象綁定功能，而且延續(xù)了很好的SQL使用經(jīng)驗，對于沒有那么高的對象模型要求的項目來說，相當(dāng)完美。?
iBATIS的缺點就是框架還是比較簡陋，功能尚有缺失，雖然簡化了數(shù)據(jù)綁定代碼，但是整個底層數(shù)據(jù)庫查詢實際還是要自己寫的，工作量也比較大，而且不太容易適應(yīng)快速數(shù)據(jù)庫修改。?
我的建議就是：?
如果你的團隊沒有Hibernate高手，那么請用iBATIS，要把Hibernate用好，并不容易；否則你應(yīng)該選擇Hibernate，那樣你的開發(fā)速度和代碼簡潔性都相當(dāng)棒！?
我覺得rails的ActiveRecord是平衡性做的最好的，避免了Hibernate的復(fù)雜性和學(xué)習(xí)HQL的成本，同時具備iBATIS即學(xué)即用的簡單性。

說明：本文轉(zhuǎn)自：http://robbin.javaeye.com/blog/24529

我為什么選擇 iBatis而不是 Hibernate(對于正在選型的人的建議)
1. iBatis易于掌握。拿來文檔看半天到兩天就可以掌握了。?
Hibernate可能需要3倍以上的時間來掌握。?

2. iBatis更容易進行sql的優(yōu)化。?
這個應(yīng)該大家都有共識了。另外Hibernate生成的sql也實在是太難看了。鑒于有的朋友提到了sql不太重要。我想在這里強調(diào)一下我的經(jīng)驗，一般系統(tǒng)性能的瓶頸都在數(shù)據(jù)庫上。所以這一點是iBatis非常重要的一個優(yōu)勢。?
3. iBatis 可以進行細(xì)粒度的優(yōu)化
3.1 比如說我有一個表，這個表有幾個或者幾十個字段，我需要更新其中的一個字段，iBatis很簡單，執(zhí)行一個sql：UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#?但是用Hibernate的話就比較麻煩了,缺省的情況下hibernate會更新所有字段。當(dāng)然我記得hibernate有一個選項可以控制只保存修改過的字段，但是我不太確定這個功能的負(fù)面效果。
3.2 我需要列出一個表的部分內(nèi)容，用iBatis的時候，這里面的好處是可以少從數(shù)據(jù)庫讀很多數(shù)據(jù)，節(jié)省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...?
3.2.1 一般情況下Hibernate會把所有的字段都選出來。比如說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我為什么要把他們也選出來呢？?
3.2.2 用hibernate的話，你又不能把這兩個不需要的字段設(shè)置為lazy load，因為還有很多地方需要一次把整個 domain object 加載出來。這個時候就能顯出ibatis的好處了?
3.2.3 Hibernate還有一個方案，就是生成javabean/map/object[](感謝leelun/cjmm)，但是這樣的話就可能會產(chǎn)生大量的多余class。map/object[] 的方式應(yīng)該不錯，我比較喜歡這種方式。?
3.3 如果我需要更新一條記錄（一個對象），如果使用hibernate，需要現(xiàn)把對象select出來，然后再做update。這對數(shù)據(jù)庫來說就是兩條sql。而iBatis只需要一條update的sql就可以了。減少一次與數(shù)據(jù)庫的交互，對于性能的提升是非常重要。?
4. 開發(fā)方面?
4.1 開發(fā)效率上，我覺得兩者應(yīng)該差不多?
4.2 可維護性方面，我覺得iBatis更好一些。因為iBatis的sql都保存到單獨的文件中。而Hibernate在有些情況下可能會在java代碼中保存sql/hql。?
5. 運行效率?
5.1 在不考慮cache的情況下，iBatis應(yīng)該會比hibernate快一些或者很多（根據(jù)實際情況會有所不同）。?
當(dāng)然iBatis也有比較大的缺點?
1. 不同數(shù)據(jù)庫類型的支持不好，如果你要開發(fā)的系統(tǒng)是要在對中數(shù)據(jù)間移植，那可能用hibernate比較好。?

2. 缺省的cache支持不好，但是hibernate的cache支持其實也不是很好，而且很復(fù)雜。尤其是對于大并發(fā)量的應(yīng)用。所以我更傾向于自己管理cache。

?

hibernate與ibatis比較的11大優(yōu)勢?
Hibernate在解決性能問題方面做得非常好。有了它的緩存機制，使用第三方緩存和數(shù)據(jù)庫連接池，就較好的解決的性能問題。但這些還不夠，hibernate給了開發(fā)者足夠的自由，讓開發(fā)者自己去控制性能問題。
學(xué)習(xí)了一段時間的ibatis，我覺得hibernate有著ibatis無法替代的優(yōu)勢。
1、開發(fā)者都知道，hibernate讓我們以oo的方式操作數(shù)據(jù)庫，這讓我們看到了hibernate的強大之處，體驗到操作數(shù)據(jù)的方便。但Gavin King說，hibernate最耀眼之處是hibernate的緩存機制，而不是以oo的方式操作數(shù)據(jù)庫。Hibernate的緩存機制不外乎是一級緩存session，二級緩存sessionFactory，和第三方緩存如ehcache。也就是hibernate的最強大的地方是它的緩存，理解了這個才能真正的理解hibernate。緩存實在太難了，我至今未能真正理解。
2、可維護性：ibatis宣揚寫sql語句，它將sql語句放進一個單獨的xml文件，這種方式贏得了很多開發(fā)者的喜愛，一句話，方便維護。但hibernate同樣具有這種功能，而且比ibatis更加強大。Hibernate的命名查詢/命名參數(shù)查詢，就是將hql語句放在一個單獨的xml文件之中，它仍然讓人們以面向?qū)ο蟮姆绞饺ゲ倏v數(shù)據(jù)，這得到大量遵循 oo方式開發(fā)者的喜愛，而不用在以oo的方式寫著代碼的同時，然后再轉(zhuǎn)變思維，用面向關(guān)系的方式去寫那些sql語句。但hibernate不僅做了這些， 它的native sql查詢方式，完全滿足sql語句的偏愛者，它像ibatis一樣，將sql語句放在配置文件之中。
3、性能：我堅信，hibernate性能問題不是問題。想想那么多大中小項目都在使用hibernate，你還懷疑hibernate的性能嗎？spring整合hibernate之后，在真正性能瓶頸的地方，完全可以使用spring集成的jdbc，或直接寫存儲過程得了。但首先得確認(rèn)，這實在是性能瓶頸的地方，我想，不應(yīng)想當(dāng)然的認(rèn)為性能的問題，所謂的性能問題阻撓了很多人。我認(rèn)為，性能的好壞無外是發(fā)送sql語句的多少而已。性能好，發(fā)送的sql語句少，性能差，就是發(fā)送大量的sql語句。Hibernate在解決性能問題方面做得非常好。有了它的緩存機制，使用第三方緩存和數(shù)據(jù)庫連接池，就較好的解決的性能問題。但這些還不夠，hibernate給了開發(fā)者足夠的自由，讓開發(fā)者自己去控制性能問題。
我認(rèn)為開發(fā)者可以在以下幾個方面自行調(diào)優(yōu)：
a、在查詢字符串中，應(yīng)該總是使用jdbc的占位符？，或使用使用命名參數(shù)：，不要自查詢中使用字符串值來代替非常量值。
b、Flush會影響性能，頻繁刷新影響性能，盡量減少不必要的刷新。
c、Cascade策略，在幾對幾的關(guān)系，正確設(shè)置cascade策略，想清楚在操作對象A的同時是否需要級聯(lián)操作對象B，比如在one to many的父子關(guān)系中，刪除了父親one，需級聯(lián)刪除子many，這時的one這端可設(shè)置cascade="delete"，這樣在刪除one時，會自動刪除子，但對子的操作不會影響父。Cascade還有其他的屬性值，只要設(shè)置正確，可提升性能。
d、lazy策略，正確設(shè)置延遲加載策略同樣會提升性能，在one to many或many to many中，通常總應(yīng)該延遲加載many的一方的到內(nèi)存。設(shè)置了lazy="true"，首先發(fā)送sql語句，加載自己到內(nèi)存，到需要時才加載級聯(lián)對象；lazy="false",則會同時加載自己和級聯(lián)對象到內(nèi)存。
e、另外還有集合的性能(set、list、map、array)，都應(yīng)正確設(shè)置。
f、正確使用第三方緩存，在讀操作頻繁寫操作不多的情況，使用第三方緩存可大幅度提升性能，如ehcache的緩存策略有：read-only，read-write和notstrict-read-write。
f、 隨著hibernate新版本的發(fā)布，和技術(shù)的發(fā)展，我相信hibernate的性能會越來越好，所有性能不是不使用hibernate的原因。
4、hibernate不僅僅作為持久層的orm框架存在，它除了dao層的持久化操作外，還有很多。
在注解annotation已經(jīng)走向主流的今天，hibernate 迅速響應(yīng)，讓xml部署描述符成為可選的。Hibernate annotation對大字段的處理只是一個@Lob就搞定了。
hibernate search對Lucene進行了輕量級的封裝，全文檢索變得非常簡單。
Hibernate validator被認(rèn)為是最合理的驗證方式，將驗證策略直接附在貫穿各層的領(lǐng)域模型domain上，不再需要哪些web框架的xml方式的驗證，代碼中不再出現(xiàn)大量的非空/null的判斷。
5、jbpm，Jbpm業(yè)務(wù)流程引擎的持久層采用hibenrnate來實現(xiàn)，要想使用jbpm，hibernate是必須的。我想，業(yè)務(wù)流程管理無比重要，在SOA迅速發(fā)展的今天，如果實施SOA項目，業(yè)務(wù)流程管理是必然和必須的。因為soa就是業(yè)務(wù)和it技術(shù)的融合，是業(yè)務(wù)流程管理和it基礎(chǔ)架構(gòu)的融合。在soa中，業(yè)務(wù)管理是第一位的，這需要相應(yīng)的技術(shù)來實現(xiàn)該業(yè)務(wù)流程管理。開源領(lǐng)域的jbpm我想會是首選。所以，為了將來有可能實施soa項目，為了實現(xiàn)soa的業(yè)務(wù)流程管理，應(yīng)該使用hibernate。
6、大家都知道，hibernate將ejb2時代的實體bean趕進了歷史，而ejb3的jpa標(biāo)準(zhǔn)也只不過是hibernate的子集而已。jsr規(guī)范請求的威力是巨大的，沒有各種jsr規(guī)范請求，就不會有各種應(yīng)用程序框架，各種應(yīng)用程序框架只是那些jsr規(guī)范請求的實現(xiàn)者。jpa作為持久層的規(guī)范標(biāo)準(zhǔn)，引導(dǎo)持久層orm框架的方向，jpa同樣以面向?qū)ο蟮姆绞讲僮鲾?shù)據(jù)庫，而不是寫sql語句。規(guī)范標(biāo)準(zhǔn)都完全orm，不寫sql了，你還有理由不跟著它嗎？
7、Spring+hibernate+范型+可變參數(shù)，這是一個非常強大的組合，對應(yīng)普通的crud操作，你不再需要重復(fù)寫那些煩人的相似的dao層和manager層的代碼，僅僅需要寫一次，就完成了所有大量的crud操作。Ibatis盡管也支持范型，但始終沒有hibernate支持的好
8、Jboss，hibernate是jboss的項目，jboss的所有項目的持久層都采用的hibernate，要知道，jsr規(guī)范組的專家們大多數(shù)是來自jboss的，在一定程度上說，jboo引領(lǐng)著java的發(fā)展方向。使用hibernate，跟著jboss，不偏離java的發(fā)展方向。
9、Gavin King，我最崇拜的偶像，他不僅發(fā)明了強大的hibernate，還搞出了同樣強大且優(yōu)雅的web2.0應(yīng)用程序框架seam。他是ejb3.0專家組成員之一，是jpa規(guī)范請求的領(lǐng)導(dǎo)者，他java領(lǐng)域最有發(fā)言權(quán)、最權(quán)威的領(lǐng)袖人物之一。現(xiàn)在，他領(lǐng)導(dǎo)web bean的，jsr299的發(fā)展，web bean規(guī)范的制定，全球軟件巨頭如ibm、oracle、bea和apache沒有一個反對，紛紛響應(yīng)。Web bean，想象起來，實在太美好了，完全的松耦合和強類型，所有的應(yīng)用組件生活在一個應(yīng)用組件上下文context中，相互合作。那時將不再有各種各樣的上下文環(huán)境，不再有struts2的ActionContext，不再有spring的ApplicationContext，不再有hibernate 的session，不再有持久化上下文，不再有事務(wù)上下文，不再有安全上下文，所有組件生活在一個大家庭中，大家其樂融融，實現(xiàn)天下的大和平。
10、 osgi，我認(rèn)為現(xiàn)在最值得學(xué)習(xí)的一個技術(shù)，有了osgi，實現(xiàn)真正的多模塊開發(fā)，改變傳統(tǒng)的開發(fā)方式。現(xiàn)在，已經(jīng)有了hibernate osgi，spring dynamic modul(osgi),struts 2同樣實現(xiàn)了對osgi的支持。目前，eclipse是基于osgi開發(fā)的，ibm的websphere v6.1，bea的所有產(chǎn)品都重構(gòu)在osgi上，spring的應(yīng)用服務(wù)器同樣基于osgi，在EclipseCon2007上，osgi成為了主要的話題。Osgi受到如此的待遇，一點不奇怪，因為他具有無比強大的功能，改變傳統(tǒng)的軟件開發(fā)方式。Osgi采用樹設(shè)計模式，將一個項目分成多個模塊(bundle)，每個模塊單獨部署，單獨運行，說白了，就是將一個工程分成許多的插件，每個插件單獨開發(fā)，重復(fù)使用，實現(xiàn)完全的即插即用。太令人激動了。如果公司的軟件開發(fā)基于osgi，將會有大量的重復(fù)使用的osgi bundles，公司將會積累大量的無形資產(chǎn)，軟件開發(fā)將會越來越快。而ibatis現(xiàn)在還沒見到對osgi的支持。
11、hibernate的社區(qū)非常繁榮，ibatis則相對平靜。
綜述，hibernate還有很多優(yōu)秀的特點，只是我們不知道。Hibernate與ibatis，就像大家閨秀對小家碧玉，大家閨秀不僅具有小家碧玉的全部，而且知名度更高，更受尊敬，更受人追捧，更有發(fā)展前途。小家碧玉盡管也很有魅力，但始終比上大家閨秀。
Hibernate所做的不僅僅是dao層的持久化工作，而ibatis恰恰如此。
選擇hibernate，選擇orm的王者，選擇更全面的工作體驗，選擇更高效的工作方式，選擇更多的利潤；選擇Gavin King，跟著領(lǐng)袖走；選擇jboss，追隨開源的潮流，不偏離java的發(fā)展方向。
一切都不是借口。一切都在發(fā)展，hibernate會越來越好。

本文來自:http://blog.sina.com.cn/s/blog_4adc4b0901010kcx.html

?

Hibernate與IBatis的優(yōu)缺點及可行性分析

1.優(yōu)點
簡單：
易于學(xué)習(xí)，易于使用，通過文檔和源代碼，可以比較完全的掌握它的設(shè)計思路和實現(xiàn)。
實用：
提供了數(shù)據(jù)映射功能，提供了對底層數(shù)據(jù)訪問的封裝（例如ado.net），提供了dao框架，可以使我們更容易的開發(fā)和配置我們的dal層。
靈活：
通過sql基本上可以實現(xiàn)我們不使用數(shù)據(jù)訪問框架可以實現(xiàn)的所有功能，或許更多。
功能完整：
提供了連接管理，緩存支持，線程支持，（分布式）事物管理，通過配置作關(guān)系對象映射等數(shù)據(jù)訪問層需要解決的問題。提供了dao支持，并在dao框架中封裝了ado.net，Hibernate和datamapper.增強系統(tǒng)的可維護性：通過提供dal層，將業(yè)務(wù)邏輯和數(shù)據(jù)訪問邏輯分離，使系統(tǒng)的設(shè)計更清晰，更易維護，更易單元測試。sql和代碼的分離，提高了可維護性。
2.缺點
滯后性：
還沒有明確對。net2.0的支持。最新版本在2.0下編譯可以，但有些單元測試不能通過。
不成熟，工程實踐較少：ibatisnet在實際項目中的使用較少。只是理論上可行。
半orm，工具支持較少：需要我們自己寫sql，并且。net下還未發(fā)現(xiàn)可以自動生成業(yè)務(wù)層類和配置文件的工具，這點和Hibernate不一樣，Hibernate會為我們的數(shù)據(jù)庫直接產(chǎn)生sql，并有一些輔助工具。因此使用ibatis比Hibernate要多做一些工作。
3.可行性
沒有最好的框架，只有最適合的框架。存在的便是合理的，它存在就說明有它存在的道理。但它未必為我們存在。所以選擇一個框架最主要的是看它對你有沒有意義，意義有多大，是不是比其他框架帶給你的好處要多。沒有絕對的優(yōu)點也沒有絕對的缺點，重要的是看在什么情況下討論。
上面說了部分的ibatis的優(yōu)點和部分缺點。這些優(yōu)點從理論上證明ibatis對任何數(shù)據(jù)持久層都合適，但未必是最好的選擇。下面對上面的優(yōu)缺點分別從兩方面討論。
簡單：
我們都喜歡簡單，簡單意味著學(xué)習(xí)成本低，使用中出錯的可能性低。同時，簡單的東西一般來說功能不夠強大。反過來，復(fù)雜的東西學(xué)習(xí)成本高，用起來不方便，并且團隊沒有很強的技術(shù)實力，一般不要使用。
實用：
解決了項目中需要解決的問題，這是任何實際工程中采用的框架和工具都應(yīng)具有的性質(zhì)，否則就不要拿到實際項目中來。
靈活：
靈活有兩層意思，一種是簡單易擴展，另一種是功能強大提供了很多選項。ibatis屬于前者，Hibernate屬于后者。兩者各有優(yōu)缺點。
功能完整：
ibatis的功能完整也是相對的，比我們自己開發(fā)的框架應(yīng)該完整，但對比其他框架肯定也有一些解決不了的問題。
增強系統(tǒng)的可維護性：利用ibatis可以做到sql和代碼分離，可以設(shè)計出一個清晰的數(shù)據(jù)訪問層（dal）。但項目架構(gòu)是否科學(xué)合理，是否以維護，關(guān)鍵 不在ibatis，因 為它只是一個數(shù)據(jù)層框架。但是我們也不得不清楚，要想發(fā)揮ibatis的優(yōu)勢，我們需要做一些額外工作，比如最好設(shè)計dao接口，需要將業(yè)務(wù)層實體和對實 體的訪問放在不同的工程中，同時需要維護xml配置文件。
滯后性：
ibatis組現(xiàn)在還沒有提到要支持。net2.0，很多人在。net2.0下使用ibatis都出現(xiàn)了問題。所以如果要使用。net2.0開發(fā)，ibatis不是一個好選擇，還需要等待。
不成熟：
開源的東西很難說成熟，但一般比我們自己寫的框架要成熟。由于我們可以拿到他的源代碼，所以關(guān)鍵在于我們能否駕馭它。
半orm，工具支持少：
這注定了ibatis不能從本質(zhì)上提升開發(fā)效率，我們需要自己寫sql，寫實體類，寫配置文件。但這也是它優(yōu)越的地方，它沒有為我們做的他多，所以我們就 有更多的施展空間。而且它非常適合那些并不能完全控制數(shù)據(jù)庫的系統(tǒng)和需要利用數(shù)據(jù)庫本身提供的高級特性的統(tǒng)計查詢系統(tǒng)的開發(fā)。
使用ibatis需要自己寫sql，由于我們的sql不可能完全符合sql標(biāo)準(zhǔn)，比起Hibernate產(chǎn)生的sql來，可移植性差。不過由于我們更改 數(shù)據(jù)庫的可能性較小，對我們來說sql符合標(biāo)準(zhǔn)以便可以在遷移到不同服務(wù)器時代價最小并不是十分必要的。另一方面，Hibernate雖然可以屏蔽很多 數(shù)據(jù)庫間的不同，但是卻很難利用某些數(shù)據(jù)庫的高級特性，比如oracle的分析統(tǒng)計函數(shù)。
Hibernate不適合數(shù)據(jù)庫模式不規(guī)范，約束不完整，需要大量復(fù)雜查詢的系統(tǒng)，同時Hibernate的學(xué)習(xí)成本較高，完全掌握Hibernate也較困難，風(fēng)險較大。
自己寫框架未必比ibatis的好，穩(wěn)定，強大和可擴展。而且自己開發(fā)框架也需要較大的工作量。
如果使用dotnet并且要選一個數(shù)據(jù)層框架，而系統(tǒng)中有相當(dāng)一部分較復(fù)雜的sql，或數(shù)據(jù)庫設(shè)計不合理，臟數(shù)據(jù)多，對性能和資源要求嚴(yán)格，ibatis是一個比較不錯的選擇。他的那些缺點并不是致命的，而且也是有一些解決方案的。尤其是，當(dāng)選用了ibatis的dataaccess作為dao框架時，我們可以同時使用Hibernate，ado.net和datamapper（ibatisnet的核心組件），那樣將會使風(fēng)險降到最低，并且整個系統(tǒng)的框架比較合理。
另外，利用ibatis可以統(tǒng)一編碼風(fēng)格，節(jié)約開發(fā)成本，大家不會再把精力浪費到分頁 連接池 主鍵生成等地方了，可以集中精力進行業(yè)務(wù)組件的編寫。
綜上：很多時候我們要在是自己開發(fā)框架和選用第三方框架和選用什么樣的框架問題上進行綜合考慮。考慮的標(biāo)準(zhǔn)當(dāng)然是項目的當(dāng)前情況和我們希望達到目的的一個平衡。
ibatis只是封裝了數(shù)據(jù)訪問層，替我們做了部分的對象關(guān)系映射。但我們的代價是必須要寫xml配置文件，相對于Hibernate我們還要寫很多 sql.Hibernate通過工具直接從數(shù)據(jù)庫模式生成實體類和基本的配置文件，而且大部分情況下不需要我們寫sql，會較大的提升開發(fā)效率。但這些也 有很多的局限性，尤其是對環(huán)境的要求較高（數(shù)據(jù)庫設(shè)計，對象設(shè)計，團隊的協(xié)作等）。
個人感覺ibatis對項目比較有意義的地方在于它小巧靈活，可擴展，封裝了數(shù)據(jù)訪問層（事務(wù)，緩存，異常，日志），并提供了dao框架支持。
利用ibatis我們可以做到代碼和sql的分離，只要sql能夠解決的問題，ibatis就能幫我們較容易的解決，同時也使我們的項目對某一框架的依賴性變小（因為ibatis是非侵入性的）。這將極大的降低項目風(fēng)險，減少解決復(fù)雜問題的時間，使項目的維護變得簡單。
ibatis對于應(yīng)用的修改，調(diào)試，擴充和維護將會變得容易自然。修改時，我們主要修改的是代表模型的實體對象，xml配置文件中的sql，和/或配置文 件的resultmap（很多時候是不需要的）。同時，sql和代碼分離，我們不用在代碼的stringbuffer的append方法之間尋找需要修改 的sql.配置文件中的sql便利了我們的調(diào)試和對sql的評審及以后的sql重用。
利用一些框架在前期一般會拖慢開發(fā)效率。因為我們需要付出學(xué)習(xí)成本，很多時候，使用框架需要寫很多配置文件，在使用不熟時開發(fā)速度較慢；同時利用框架往往 使系統(tǒng)代碼量增大，比如model1和model2模型，開發(fā)效率應(yīng)該還是model1快，四層的架構(gòu)肯定比兩層的代碼量大。但對于中后期開發(fā)和維護將會極大的提高效率。
利用一些較完全的開發(fā)框架和代碼生成工具，在前期會較大的提高開發(fā)效率，但在后期常常會拖慢進度，并有可能成為以后維護的夢魘。比如torque生成實體類和其對應(yīng)的sql，雖大幅提高了效率，但修改負(fù)擔(dān)較大。
比較理想的開發(fā)方式是使用簡單框架結(jié)合簡單的代碼生成工具。框架提供系統(tǒng)的基礎(chǔ)服務(wù)，并規(guī)范開發(fā)。框架一方面提供了開發(fā)中某一方面的開發(fā)基礎(chǔ)支持，比如數(shù) 據(jù)訪問層，事務(wù)，日志，公用類，異常等。另一方面，也為開發(fā)定義了模式，定義了系統(tǒng)的基本輪廓。同時，通過簡單的代碼生成工具生成部分低級的代碼。比如通 過工具從數(shù)據(jù)庫模式生成實體類。這些類生成后我們可以自由修改。
Hibernate是十分強大，比較完善的orm框架，不過這是它的優(yōu)點也是它的缺點。J2EE系統(tǒng)是否采用Hibernate3，是一個需要認(rèn)真評估的問題。
要想Hibernate工作的好，數(shù)據(jù)庫的設(shè)計必須好。同時對于復(fù)雜的數(shù)據(jù)操作同時需要使用sql，Hibernate3對于直接使用sql的支持比Hibernate2要自然，這一點是可以接受的。
Hibernate比較復(fù)雜，功能強大而靈活，要用好Hibernate確實不是很簡單，當(dāng)然spring框架提供了對Hibernate的封裝，使Hibernate的使用變得簡單了點。
可以說ibatis在任何系統(tǒng)里都適用，但未必是最好選擇。不過ibatis提供的思路是我們應(yīng)該仔細(xì)考慮的。

來自:?http://blog.sina.com.cn/s/blog_4adc4b0901010kcz.html

(完)

感謝網(wǎng)友提供的資料！

?

?

FAQ:參考資料

Hibernate與iBATIS的區(qū)別與比較(帶源碼)

轉(zhuǎn)載于:https://www.cnblogs.com/kofxxf/p/3710858.html

總結(jié)

以上是生活随笔為你收集整理的【转】Hibernate和IBatis对比的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。