我为什么选择 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 的代码。欢迎大家一起来讨论。
  

评论

89 楼 mmwy 2007-04-27  

我觉得最主要的，还是看你倾向于开发效率还是运行效率

88 楼 dovecat 2007-04-27  

......解决什么问题就用什么工具.有必要一个工具用到底不?

87 楼 Arthas.Hui 2007-04-27  

林秋枫 写道

Arthas.Hui 写道

林秋枫 写道

1.未确定的表就是指即使在运行的时候也还是不能确定的表。比如你要把一张表的数据导出成xml文件，相关的映射方式在保存在配置文件中的。就是在运行的时候，这次你导出的是a表，下次运行导出的可能就是C表。永远不能确定使用的是哪张表，也不可能确定是哪个类了。除非动态生产class，动态加载。
用jdbc根本不用hard coded每个相关表的细节。就是操作表的sql是根据配置文件动态产生的。所以新增加一个字段或者少一个字段，甚至换表都只需要修改配置文件就可以了。根本不用改代码。

2.实际应用中，有需要对两张千万级别的表所有记录的某个类似属性进行比对，得出比对统计结果。
jdbc绝对没有问题。不知道Hibernate怎么实现，难道把所有数据都缓存吗？还是用什么方法？

具体的例子阿。。。等着你的例子呢。。。。

简单的例子，你要把一个表里面的是数据导出成xml或者insert的sql脚本。
比如在配置文件里面：
<table> t1 </table>
<colume1> code </colume1>
<colume2> name </colume2>
<condition> code!=1000 </condition>

你在代码里面很容易生产动态的sql语句：select  config.get("colume1"),config.get("colume2") from config.get("table") where config.get("condition")

rugu如果用户要改成其他的表或者字段，只需要修改配置文件即可。

这个例子太无聊了。。。

<class> t1 </class>
<property1> code </property1>
<property2> name </property2>
<condition> code!=1000 </condition>

你在代码里面很容易生产动态的hql语句：select a.config.get("colume1"),a.config.get("colume2") from config.get("table") a where config.get("condition")
如果用户要改成其他的表或者字段，只需要修改配置文件即可。

86 楼 林秋枫 2007-04-27  

Arthas.Hui 写道

林秋枫 写道

1.未确定的表就是指即使在运行的时候也还是不能确定的表。比如你要把一张表的数据导出成xml文件，相关的映射方式在保存在配置文件中的。就是在运行的时候，这次你导出的是a表，下次运行导出的可能就是C表。永远不能确定使用的是哪张表，也不可能确定是哪个类了。除非动态生产class，动态加载。
用jdbc根本不用hard coded每个相关表的细节。就是操作表的sql是根据配置文件动态产生的。所以新增加一个字段或者少一个字段，甚至换表都只需要修改配置文件就可以了。根本不用改代码。

2.实际应用中，有需要对两张千万级别的表所有记录的某个类似属性进行比对，得出比对统计结果。
jdbc绝对没有问题。不知道Hibernate怎么实现，难道把所有数据都缓存吗？还是用什么方法？

具体的例子阿。。。等着你的例子呢。。。。

简单的例子，你要把一个表里面的是数据导出成xml或者insert的sql脚本。
比如在配置文件里面：
<table> t1 </table>
<colume1> code </colume1>
<colume2> name </colume2>
<condition> code!=1000 </condition>

你在代码里面很容易生产动态的sql语句：select  config.get("colume1"),config.get("colume2") from config.get("table") where config.get("condition")

rugu如果用户要改成其他的表或者字段，只需要修改配置文件即可。

85 楼 林秋枫 2007-04-27  

林秋枫 写道

daquan198163 写道

ltian 写道

用户可不追求代码的优雅,用户追求的是性能和稳定,如果哪位用Hibernate做过处理百万数据以上的复杂计算,比如说电力或者电信的客户算费系统,而且能够获得用户在性能方面的肯定,能让我们学习一下也是好的!

用hibernate调用存储过程

用hibernate调用存储过程还要hibernate来干吗呢？
百万数据并不算很大，社保系统动辄千万以上，这还是一个月的数据量。

hibernate的本地sql很幽雅吗？
比JDBC恶心多了。

84 楼 林秋枫 2007-04-27  

daquan198163 写道

ltian 写道

用户可不追求代码的优雅,用户追求的是性能和稳定,如果哪位用Hibernate做过处理百万数据以上的复杂计算,比如说电力或者电信的客户算费系统,而且能够获得用户在性能方面的肯定,能让我们学习一下也是好的!

用hibernate调用存储过程

用hibernate调用存储过程还要hibernate来干吗呢？
百万数据并不算很大，社保系统动辄千万以上，这还是一个月的数据量。

83 楼 daquan198163 2007-04-27  

ltian 写道

用户可不追求代码的优雅,用户追求的是性能和稳定,如果哪位用Hibernate做过处理百万数据以上的复杂计算,比如说电力或者电信的客户算费系统,而且能够获得用户在性能方面的肯定,能让我们学习一下也是好的!

用hibernate调用存储过程

82 楼 janh 2007-04-27  

林秋枫 写道

我简单讲一些hibernate解决不了或者是存在性能问题的一些地方：
1.对未确定的表的操作。这些表可能是由用户在界面制定或者是通过配置文件制定。就是说同一个功能每次操作的表都有可能是不同的；
2.update table1 set colume1=? where id>1000 等类似问题；
3.需要对一个大数据量（超过一千万）的表每个记录做循环计算时候；
4.需要做复杂的关联统计等；
......

当然有些问题hibernate可以用数据库方言来做，但始终不是很完美的。

你用过hibernate吗，有些问题可以用hibernate的hql来完成，实在不行可以用本地sql，并且可以返回对象化的结果，难道你用jdbc特定数据库的sql来做就很优雅吗？可以说你的所有问题hibernate都可以完成。

81 楼 janh 2007-04-26  

林秋枫 写道

2.update table1 set colume1=? where id>1000 等类似问题；

这个不行吗？

80 楼 ray_linn 2007-04-26  

daquan198163 写道

关于hibernte对于遗留系统(DB)集成的问题，可以看看这本书
http://www.theserverside.com/tt/articles/article.tss?l=JavaPersistenceHibernate

一本书说明不了问题,效率低下而已.

79 楼 klyuan 2007-04-26  

"另外， iBatis 的第一个缺点——不同数据库类型的支持不好，足以让它输给hibernate了吧"

我们真的需要支持多种数据库吗？
很多情况下就是在淫！！！！

更换一个数据库的代价有多大？？？？
是否真的未来会切换到其它的数据库上！！！！

在我看来，这应该从一开始就要回避！！！！
一开始就要选定一种数据库进行开发！！！！

做技术的就是总想搞出这种异想天开的需求出来！！！！

78 楼 Arthas.Hui 2007-04-26  

林秋枫 写道

1.未确定的表就是指即使在运行的时候也还是不能确定的表。比如你要把一张表的数据导出成xml文件，相关的映射方式在保存在配置文件中的。就是在运行的时候，这次你导出的是a表，下次运行导出的可能就是C表。永远不能确定使用的是哪张表，也不可能确定是哪个类了。除非动态生产class，动态加载。
用jdbc根本不用hard coded每个相关表的细节。就是操作表的sql是根据配置文件动态产生的。所以新增加一个字段或者少一个字段，甚至换表都只需要修改配置文件就可以了。根本不用改代码。

2.实际应用中，有需要对两张千万级别的表所有记录的某个类似属性进行比对，得出比对统计结果。
jdbc绝对没有问题。不知道Hibernate怎么实现，难道把所有数据都缓存吗？还是用什么方法？

具体的例子阿。。。等着你的例子呢。。。。

77 楼 林秋枫 2007-04-26  

1.未确定的表就是指即使在运行的时候也还是不能确定的表。比如你要把一张表的数据导出成xml文件，相关的映射方式在保存在配置文件中的。就是在运行的时候，这次你导出的是a表，下次运行导出的可能就是C表。永远不能确定使用的是哪张表，也不可能确定是哪个类了。除非动态生产class，动态加载。
用jdbc根本不用hard coded每个相关表的细节。就是操作表的sql是根据配置文件动态产生的。所以新增加一个字段或者少一个字段，甚至换表都只需要修改配置文件就可以了。根本不用改代码。

2.实际应用中，有需要对两张千万级别的表所有记录的某个类似属性进行比对，得出比对统计结果。
jdbc绝对没有问题。不知道Hibernate怎么实现，难道把所有数据都缓存吗？还是用什么方法？

76 楼 林秋枫 2007-04-26  

我简单讲一些hibernate解决不了或者是存在性能问题的一些地方：
1.对未确定的表的操作。这些表可能是由用户在界面制定或者是通过配置文件制定。就是说同一个功能每次操作的表都有可能是不同的；
2.update table1 set colume1=? where id>1000 等类似问题；
3.需要对一个大数据量（超过一千万）的表每个记录做循环计算时候；
4.需要做复杂的关联统计等；
......

当然有些问题hibernate可以用数据库方言来做，但始终不是很完美的。

75 楼 林秋枫 2007-04-26  

hibernate出现的问题实际上是关系数据库和面向对象技术的矛盾问题。

关系数据库和面向对象技术之间的矛盾是对立统一的，他们之间有一些共性，所以hibernate这种orm框架能很好的利用这一点，这也是hibernate能够广泛应用的一个根本要素。

但是它们之间又有很大的差异性，比如说把一个对象持久化到数据库，实际上只是保持了对象的静态要素（属性），而对象的动态要素（方法）在关系数据库中是无法体现出来的。

因为orm框架这种天生的缺陷导致它不能解决实际应用的所有持久化要求。即使从设计开始就完全按照面向对象进行设计也是无法避免这些问题的，只能使问题减少而已。

74 楼 suxy 2007-04-26  

感觉楼主对hibernate还是很不了解，上面所列的hibernate的问题大部分都不是问题

73 楼 jfy3d 2007-01-05  

我写了工具来批量生成ibatis 框架下的文件

72 楼 daquan198163 2007-01-04  

关于hibernte对于遗留系统(DB)集成的问题，可以看看这本书
http://www.theserverside.com/tt/articles/article.tss?l=JavaPersistenceHibernate

71 楼 bonjoviu2 2007-01-04  

我给凑个理由，学HB花时间不是白花的，从HB过渡到JPA就是平滑过渡。

70 楼 kabbesy 2007-01-04  

前面牛人们说了很多了，随便写点自己的感受，ibatis起码有两点致命伤：
无法跨数据库（虽然有些人认为项目开发一般不用换），直接导致缺少物理分页的支持，乐观锁的透明支持等
查询缓存的粒度太大，基于statement而非entity id，基本导致entity cache不可用。

前面都说了，hb和ibatis都是基于JDBC的，本质上不会有啥区别。ibatis这样的纯sql mapping工具根本无法和hb抗衡，无非是jdbc的有益补充而已。

说hb性能有问题基本上只可能是hb的没用好，更何况长远来看hb更符合新的规范已经