我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议)

[注意]清在回复之前认真地看一下我的帖子，结合你的实际项目经验考虑一下，看看你是否能比较好地解决我所提出的Hibernate 的缺点。最好不要提一些大家都知道的泛泛的观点，这样会很浪费读者的时间并且分散大家的注意力。

非常感谢有几位对 hibernate 有深入了解的朋友给出了我这里提出的问题的 hibernate 解决方案。我提出这几个问题的初衷不是说 hibernate 无法实现这些功能。而是说他的实现比较不美，呵呵。比如说把一些 sql 嵌入到 java 代码中，我觉得这是非常不好的习惯。

v0.3 - 2007-1-1 21：1：1



我在最初的选型的时候是打算选择 Hibernate 的，在研究的过程中发现了 iBatis，经过
分析比较之后我选择了 iBatis。现在我已经使用 iBatis 完成了一个中小型的项目。这个
项目在性能、可维护性、可扩展性方面都非常令我满意。

在这个过程中我也不断的与使用过或者正在使用 Hibernate 的人进行过探讨。而且我本身
也在不断的跟进 Hibernate 的发展。

最终，我的结论是 iBatis 的选择非常正确，而且越用越喜欢它了。

当然了，我对 Hibernate 的理解还是非常有限的，所以这里的关于 Hibernate 的一些观
点的错误之处希望能够得到 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。


    非常感谢这么多朋友对这个话题很感兴趣。但是我感觉大家并没有对我第三部分提到的问题进行更深入的思考。我晚些时候会提交一些 ibatis 的代码。欢迎大家一起来讨论。
  

评论

69 楼 bingbing 2007-01-04  

cache 到处都是  cache
是什么东西呀:)
GOOGLE上不去 BAIDU还差到都是CPU什么的-.-

68 楼 风雪涟漪 2007-01-04  

如果追求OO的话,从OO->数据库设计~会发现HIBERNATE多么的便利~

67 楼 bingbing 2007-01-04  

看完了所有的帖子



谢谢,真心的谢谢
一个学习中的新人真诚的留言

---王炳焱

66 楼 bingbing 2007-01-04  

更喜欢OO  嘿嘿:)
关于楼主大哥的更新多次查询的"问题"我认为不是"问题":)
因为更新就伴随着更新情况或条件
H也可以不通过查询直接更新吧:)....

谢谢,真心的谢谢
一个学习中的新人真诚的留言

                  ---王炳焱

65 楼 chenxu 2007-01-04  

<p>hibernate的解决方案全面 ，并且适合于跨数据库的移植</p>
<p>在hibenrate3中也解决了批量删出的问题。</p>
<p>作为一个orm产品做到这种程度已经是够优秀的了!</p>

64 楼 robbin 2007-01-03  

没有必要追求过于纯粹的架构OO，需要用SQL的地方，只管用好了。特别是在使用spring HibernateTemplate的时候，可以混用JDBCTemplate，两者会共用同一数据库连接。

63 楼 iceant 2007-01-03  

robbin 写道

Hibernate对于遗留系统的支持性做的还是相当不错的，在损失掉一定的对象建模的情况下，可以良好的支持，当然Hibernate付出的代价就是框架需要做的更加复杂。这种对遗留系统的兼容态度(或者说妥协态度)和RoR的ActiveRecord刚好是两个可以参照的对比。

ORM适用的领域是OLTP，而不是OLAP。如果以大量数据分析和数据运算为主的OLAP类型的系统，不要说Hibernate，任何一个ORM都不擅长。讨论这个问题的前提是限定讨论范围。

Robbin，谢谢你回答我的问题。
我同意你的观点。任何技术其实都有一个适用的 scope，不可能是万金油，什么都能很好的解决。针对要实现的系统，选择合适的技术与策略，才比较理性。

我对 ORM 感到别扭的是，它是以 RDBMS 为基础，然后期望在 RDBMS 和 OO 之间建立起桥梁。它有Criteria Query，但是就易用性和实用性来说，肯定是没有　HQL　来得实在。可是写 HQL 又没有 SQL 来得直观，　我不知道Hibernate的专家们是否都不需要调试HQL，不用将 HQL 转成 SQL 在RDBMS里调试一下，我是经常要这样做的，因为我不确定HQL转换出来的 SQL 到底是不是我要的语句，于是我不可避免的要在 RDBMS 和 OO 之间来转换。所以我不太明白，怎么可能抛开 RDBMS ，完全基于 OO 去实现一个系统。

62 楼 ceder 2007-01-03  

都是以JDBC为基础的，相信两者的执行性能不会真差到哪里去，两者也不会真有什么东西一定是你能做，我就搞不定的。

至于选择哪一个，影响决断的因素应该在技术之外了。

61 楼 robbin 2007-01-03  

Hibernate对于遗留系统的支持性做的还是相当不错的，在损失掉一定的对象建模的情况下，可以良好的支持，当然Hibernate付出的代价就是框架需要做的更加复杂。这种对遗留系统的兼容态度(或者说妥协态度)和RoR的ActiveRecord刚好是两个可以参照的对比。

ORM适用的领域是OLTP，而不是OLAP。如果以大量数据分析和数据运算为主的OLAP类型的系统，不要说Hibernate，任何一个ORM都不擅长。讨论这个问题的前提是限定讨论范围。

60 楼 iceant 2007-01-02  

daquan198163 写道

flyspider 写道

帖子里是人家对ORM的一些看法，怎么就成了“臆想和猜测”了？软件设计过程中必然存在审时度势的折衷，走极端往往过犹不及，如果您很会用hibernate，请给兄弟们说说你如何让Hibernate很少在POJO与RDBMS Model之间转换？

如果采用“领域建模-〉写XDoclet或ejb3.0标注-〉自动生成数据库模式”的流程来使用hibernate就可以免去这个麻烦

我承认我对Hibernate的理解并不深入，代码也没有仔细的读一读，对你所说的工具，我一样都没有用过。很是惭愧～

很高兴能见到对Hibernate很熟悉的人！我现在有个问题想要请教一下，在我看来要解决 CRUD　的基本操作都是比较简单的。就算是JDBC，我们也写过代码自动生成的工具，可以根据一些META信息(如DDL或PowerDesigner 的PDM)自动生成 Java 对象，并生成相关的 CRUD 代码。但是一般出报表才是比较麻烦的。

如果是以对象的方式来load数据，再进行加工处理，那会load很多不必要的数据，严重影响系统的性能。一般来说我们会根据报表的需要，产生一些中间视图或TEMP表（这些数据可能来自很多不同的系统），只取需要的数据进行分析和处理。不知道你说的这些工具是否能完成这样的任务呢？

另外，你所说的工具似乎比较适合从零开始设计开发的系统，但是往往我们不得不与现有的系统进行集成，有些是我们自己做的，有些是别的公司做的，像 ClearQuest/Documentum/TeamTrack etc.在这种情况下，不知道你说的工具还能很好的支持吗？

谢谢你抽时间来回答我的问题

59 楼 jiming 2007-01-02  

引用

jeffrey_gao     5 小时前

我原先公司的一个项目从04年开始就用iBATIS了，坚持了两年，还是转向了Hibernate. 说白了，iBATIS只是一个SQL Map的工具，方便你将原先混杂在程序中的SQL语句提炼出来，并且用一些第三方提供的Cache算法提高语句执行效率.

能讲讲为什么吗？

58 楼 ahuaxuan 2007-01-02  

同意楼上,看了上面这么多讨论还是那样,什么优雅不优雅的问题都非常的主观,特别是楼主贴了很长的代码和sql语句后说:很优雅!! 但是一千个观众就有一千个哈姆雷特.在我看来很不优雅(仅一家之言).比如说

1,更新的问题,楼主非说sql,或者hsql只能写在java代码中,其实这些语句都是可以写在映射文件中的，根本没有必要写在java代码中,如果对hibernate有比较深入的研究是不会不知道这一点的

2,其实深入浅出hibernate上对ibatis和hibernate的适用场景有很详细的描述很有道理, 大家不防一看.

3,看到有人说hibernate的开发效率不比ibatis高,我觉得很疑惑,我用过jdbc和hibernate,用hibernate做过好几个项目,深知hibernate比jdbc的开发效率高得多,这个是从实践中得到的，有句话说得好,用过之后才知道,只看看文旦对hibernate的在真实项目中的效率是不会有深刻认识的.

hibernate确实可以缩短开发周期,通过hibernate,我们能以惊人的速度修改数据结构.

hibernate最差的地方是不允许你轻松控制如何查询数据,并且有一些查询的效率非常低下,特别是在1:n,和m:n查询的时候,查询更加复杂,但是无论如何,这不是hibernate的一个缺点,而是技术特性,但是hibernate也给了我们弥补的机会,就是hsql和原生sql.

任何对hibernate或者ibatis一板子打死人都是对hibernate或者ibatis不了解的人,这一点是确定无疑的

57 楼 downpour 2007-01-02  

这个帖子怎么还没有结啊，讨论了那么久，有啥意思，爱用啥用啥。都各有优势的ORM框架，何必争个你死我活呢。框架的选择是根据项目的实际情况而言的，不是一概而论的。

楼主也不要过于执着了，iBatis和Hibernate的优劣是不可比较的，不用过分强调哪个好哪个不好。

老实说，楼主贴的这几百行的代码和配置，就是为了解决这几个小问题，实在没有看出优美的地方。尤其是你那280行的SQL配置，敲键盘敲的手挺酸吧。我可以告诉你，Hibernate对于Dynamic Update和Select部分字段都有比你优美得多得解决方案，只是你还不知道这些方案，没有研究透彻而已。

所以，还是潜心研究好自己的代码，少发言。

56 楼 jeffrey_gao 2007-01-02  

我原先公司的一个项目从04年开始就用iBATIS了，坚持了两年，还是转向了Hibernate. 说白了，iBATIS只是一个SQL Map的工具，方便你将原先混杂在程序中的SQL语句提炼出来，并且用一些第三方提供的Cache算法提高语句执行效率.

55 楼 cjmm 2007-01-02  

cxd110 写道

together 写道

简单一点说，很多人选择A而不选择B，都是因为先入为主。

客观的说，从长远来考虑，还是应该采用HB。比如现在我们的系统，如果需要部署到oracle/mssql/db2/mysql/pg/hsql/firebird，所需要做的只是加一个JDBC驱动，再改一下hb.cfg.xml中连接数据库的配置。这一点是IBATIS无论如何也做不到的。

这种需求具有普遍性吗，你们的项目会在中途改变数据库吗

会。
我现在就从mysql往postgresql切。呵呵。

54 楼 cjmm 2007-01-02  

要优雅是吧。
使用dynamic-update和dynamic-insert

<class
name="ClassName" (1)
table="tableName" (2)
discriminator-value="discriminator_value" (3)
mutable="true|false" (4)
schema="owner" (5)
catalog="catalog" (6)
proxy="ProxyInterface" (7)
dynamic-update="true|false" (8)
dynamic-insert="true|false" (9)
select-before-update="true|false" (10)
polymorphism="implicit|explicit" (11)
Basic O/R Mapping
Hibernate 3.2.0.ga 50
where="arbitrary sql where condition" (12)
persister="PersisterClass" (13)
batch-size="N" (14)
optimistic-lock="none|version|dirty|all" (15)
lazy="true|false" (16)
entity-name="EntityName" (17)
check="arbitrary sql check condition" (18)
rowid="rowid" (19)
subselect="SQL expression" (20)
abstract="true|false" (21)
node="element-name"
/>

(8) dynamic-update (optional, defaults to false): Specifies that UPDATE SQL should be generated at runtime
and contain only those columns whose values have changed.
(9) dynamic-insert (optional, defaults to false): Specifies that INSERT SQL should be generated at runtime
and contain only the columns whose values are not null.
(10) select-before-update (optional, defaults to false): Specifies that Hibernate should never perform an
SQL UPDATE unless it is certain that an object is actually modified. In certain cases (actually, only when a
transient object has been associated with a new session using update()), this means that Hibernate will
perform an extra SQL SELECT to determine if an UPDATE is actually required.

Note that the dynamic-update and dynamic-insert settings are not inherited by subclasses and so may also be
specified on the <subclass> or <joined-subclass> elements. These settings may increase performance in
some cases, but might actually decrease performance in others. Use judiciously.
Use of select-before-update will usually decrease performance. It is very useful to prevent a database update
trigger being called unnecessarily if you reattach a graph of detached instances to a Session.
If you enable dynamic-update, you will have a choice of optimistic locking strategies:
• version check the version/timestamp columns
• all check all columns
• dirty check the changed columns, allowing some concurrent updates
• none do not use optimistic locking
We very strongly recommend that you use version/timestamp columns for optimistic locking with Hibernate.
This is the optimal strategy with respect to performance and is the only strategy that correctly handles modifications
made to detached instances (ie. when Session.merge() is used).

53 楼 cxd110 2007-01-02  

together 写道

简单一点说，很多人选择A而不选择B，都是因为先入为主。

客观的说，从长远来考虑，还是应该采用HB。比如现在我们的系统，如果需要部署到oracle/mssql/db2/mysql/pg/hsql/firebird，所需要做的只是加一个JDBC驱动，再改一下hb.cfg.xml中连接数据库的配置。这一点是IBATIS无论如何也做不到的。

这种需求具有普遍性吗，你们的项目会在中途改变数据库吗

52 楼 alin_ass 2007-01-01  

各位牛人们，你们有大型hibernate项目经验的话回答下我的疑惑

http://www.iteye.com/topic/42667


目前我觉得有的是ibatis可以完成hibrenate不能完成的项目

51 楼 ray_linn 2007-01-01  

together 写道

简单一点说，很多人选择A而不选择B，都是因为先入为主。

客观的说，从长远来考虑，还是应该采用HB。比如现在我们的系统，如果需要部署到oracle/mssql/db2/mysql/pg/hsql/firebird，所需要做的只是加一个JDBC驱动，再改一下hb.cfg.xml中连接数据库的配置。这一点是IBATIS无论如何也做不到的。

这种也是设想的需求, 我的系统用ibatis jdo2 和hibernate同时实现过一次,DB可以选择到ms sql mysql 和orcael,DAO可以是ibatis 还是jdo2 还是hibernate. (当时弄这个,只是为了随时附和客户的要求而已).

所以这不是ibatis的问题,是技术功底问题.

50 楼 ray_linn 2007-01-01  

你们这些人,整个就是技术无聊分子.

有什么是hibernate可以完成ibatis不能完成的项目么? 没有

有什么是ibatis可以完成hibrenate不能完成的项目么? 没有

选什么技术,先看看自己的团队的技术水准,经验水平,不要做赶鸭子上架的事,真是够了!