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

评论

109 楼 lishen 2017-10-31  

caomeiliang 写道

ibatis需要写SQL
ibatis需要写SQL
ibatis需要写SQL
重要的事情说三遍
成天做一些重复的工作不烦么？update insert ，你写的不烦？
来来来，我这一个表平均30多个字段，你insert不用orm，你挨个写？
ibatis改一个数据库字段，需要把有关的SQL都改一遍，你告诉这玩意好维护？

ibatis的学习成本全部转嫁到后期的时间成本去了。

SQL是可以用工具或者自己写代码自动生成的。。。
你是不是没用过ibatis？一个表对应一个配置文件，改字段在这个文件里批量替换就行了。

其实楼主关于性能那里说的对也不对，即便使用hibernate，也完全可以配合jdbc来提高部分对性能要求高的操作

108 楼 caomeiliang 2017-07-13  

ibatis需要写SQL
ibatis需要写SQL
ibatis需要写SQL
重要的事情说三遍
成天做一些重复的工作不烦么？update insert ，你写的不烦？
来来来，我这一个表平均30多个字段，你insert不用orm，你挨个写？
ibatis改一个数据库字段，需要把有关的SQL都改一遍，你告诉这玩意好维护？

ibatis的学习成本全部转嫁到后期的时间成本去了。

107 楼 yp0123456789 2015-08-27  

这篇文章是假定h没有namesql和execute的基础之上写的。但是h是有这两种方式的。所以几乎所有的结论都是错的。

106 楼 abc382410124 2013-11-15  

jiming 写道

引用

jeffrey_gao     5 小时前

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

能讲讲为什么吗？

同求

105 楼 paladin1988 2012-08-16  

存在的都是合理的，Hibernate，ibatis既然存在肯定有其价值。。你这文章写的没有意义啊。。。

104 楼 xypcn 2012-06-23  

http://www.wikso.com/wiki/Wiki.jsp?page=DAO 最简单，最高效的DAO，完全取代iBatics 与spring集成，通过ASM动态生成类，使用maven管理

103 楼 boyszz 2012-03-02  

过儿oO 写道

jiming 写道

  
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.3 如果我需要更新一条记录（一个对象），如果使用 hibernate，需要现把对
     象 select 出来，然后再做 update。这对数据库来说就是两条 sql。而 iBatis
     只需要一条 update 的 sql 就可以了。减少一次与数据库的交互，对于性能的
     提升是非常重要。

1、首先iBatis这东西没研究过但它是不是orm的东西，从你上面提出的问题我看好像不是，因为我没有看到面向对象的东西在里面
2、你说的那个update,hibernate也可以那么写，用session就可以了，那个sql不是sql语句它只是一个字符串，而且它提供两个接口一种是为HQL准备一种是为SQL准备的，还有你更新哪个字段可以设置该对象相应的属性就完了，或者用想sql一样的语句。
3、select那个最基本的，同样可以那么写
4、不必更新前先拿出那个对象，完全可以同样的用session的那个
5、你说hql弄出来的语句难懂，但是正常都是用正常的sql语句写出来，在查询器或工具里调试好sql语句，再放上去调啊。它的根本还是来自于sql啊，对一个对象操作就不说了

你用那个iBatis能做的东西hibernate都能做，但我没看到iBatis的面向对象的一面

面向对象是用来做什么的你了解么？简化软件维护难度，提高开发效率。做到了这两个，你就成功了。做过中型项目么？PV达到多少了？进度可控么？直接编码的开发人员有怨言么？QA有怨言么？产品有怨言么？运维有怨言么？框架选型，是根据实际项目出发的，张口闭口的面向对象，有多少项目就是毁在你这种人手里。

102 楼 hfwguitar 2007-08-22  

ceder 写道

我选择用iBatis，主要是可以照搬JPetStore的架构
而且，写的SQL语句，基本可以直接拿到数据库上去执行测试。

有同感，测试起来很方便。

101 楼 过儿oO 2007-08-22  

jiming 写道

  
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.3 如果我需要更新一条记录（一个对象），如果使用 hibernate，需要现把对
     象 select 出来，然后再做 update。这对数据库来说就是两条 sql。而 iBatis
     只需要一条 update 的 sql 就可以了。减少一次与数据库的交互，对于性能的
     提升是非常重要。

1、首先iBatis这东西没研究过但它是不是orm的东西，从你上面提出的问题我看好像不是，因为我没有看到面向对象的东西在里面
2、你说的那个update,hibernate也可以那么写，用session就可以了，那个sql不是sql语句它只是一个字符串，而且它提供两个接口一种是为HQL准备一种是为SQL准备的，还有你更新哪个字段可以设置该对象相应的属性就完了，或者用想sql一样的语句。
3、select那个最基本的，同样可以那么写
4、不必更新前先拿出那个对象，完全可以同样的用session的那个
5、你说hql弄出来的语句难懂，但是正常都是用正常的sql语句写出来，在查询器或工具里调试好sql语句，再放上去调啊。它的根本还是来自于sql啊，对一个对象操作就不说了

你用那个iBatis能做的东西hibernate都能做，但我没看到iBatis的面向对象的一面

100 楼 sslaowan 2007-08-21  

iceant 写道

我不喜欢Hibernate，也不喜欢所谓的OO，大家可以冷静的想想，有多少系统是真正使用的 OO 方式来设计和实现的呢？

OO只是一种思考方式，它可以有助于开发人员了解和分析系统，抽象出系统中的各种元素。但是真正实现，还是要使用传统的各种方法与技术。OO不能解决你所有的问题，言必谈OO，不一定真正的了解OO.

我说个简单点的，有谁能用纯OO实现一个系统，然后又能很好的控制事务的？　

        使用OO，在维护时才会发现好处；使用框架，也是在维护时才会发现好处。
         越是大项目越是如此，面向过程使得过程间难于解耦，系统扩展起来比较痛苦，我们上一个项目就是面向过程的，现在改为面向对象了。

iceant 写道

最后我想说，在没有ORM的时候，我们一样能做出系统，而且性能也不差，系统一样可以维护，为什么一定要用ORM？有个朋友说，这些技术只是让程序员舒服了，但是软件不见得就强壮多少。我想这句话很有道理。

         因为目前仍然没有银弹，才会有人不断发明各种各样的新技术，我觉得大多数国人还是太懒，不愿意更新自己的知识。
          还是觉得Rod Johnson说的好，程序代码越少，需要维护的代码就越少。ORM避免了关系数据库到对象的转换成本，个人认为是一大进步。

99 楼 向左看齐 2007-08-21  

楼主不要郁闷,有些朋友说的对,这不是技术的问题.这也不是某个人的问题,是一群人的问题,也就是公司文化的问题.这种公司文化的问题比较难处理.这样的公司文化,不说公司前景怎样,单看个人发展提高的空间就实在是太有限了,建议楼主换个公司算了.
如果想留下来把公司发扬光大,首先考虑一下公司文化建设.给同事们分析清楚如何提升个人价值,是保守的人成长的快还是开放的人成长的快,这是一个不言自明的问题.个人技术上的保守至少导致个人技术上的不长进.个人不成长公司自然就不成长了.说实话,一个公司很可能几年后就倒闭了,但是个人却是要在社会上继续奋斗一生的.如果你这个团队中每个人都觉得他拿着jdbc就可以混一辈子饭吃,那楼主只有走人了,因为这样的团队成不了事业,这样的团队组成的公司成不了事业,在这样的公司的个人也自然成不了事业,所谓道不同不相与谋,赶紧走人,不要浪费自己和他人的青春.

98 楼 lly520 2007-08-14  

对于原来用sql开发的我觉得现在改用sqlmap最好不过了，在我看来一般一个项目迁移数据库的几率很小，hibernate虽然很oo，但是oo也并不是什么非常好的东西，有时候太oo会导致运行效率的降低。我觉得对于中型的系统非常适合sqlmap，至于两者谁的效率高就很难说了。

97 楼 caihemm2 2007-07-13  

ibatis 最大的好处在于把sql从java中剥离出来

96 楼 viway 2007-07-06  

像一些简单的程序,如:员工资料管理,就只需要提供数据库表名,和POJO名字就可以从MODEL,DAO,ACTION,JSP PAGE统统搞定..页面稍加修改就可以了,系统采用SPRING+springJDBC+STRUTS架构

95 楼 viway 2007-07-06  

好像用Hibernate调用DB PROCEDURE不是很灵活!而且PROCEDURE往往会影响到缓存.由于我们的经理是CS开发出生,习惯用PROCEDURE去解决一些业务问题,所以我的项目也最终还是放弃了Hibernate,拿起了JDBC大刀,不过在SPRING的支持下,自己也写了个DAO 生成器(页面也可以生成),感觉开发速度跟使用Hibernate更快,嘿嘿..

94 楼 robbin 2007-05-25  

xiaomeng 写道

这天看了一下IBATIS和HIBERNATE的帖子，http://www.iteye.com/topic/41720。这个年代就是这样大家一说就是OO。传统的面向过程在现在开发中用起来有点吃力了，都改用了XP。随着时代的发展项目的工作量也越来越大，基本上告别单兵作战的年代。分工也越来越细，原有OO分析方法就用来描述更多的东西，连数据库也用OO来做了。
    我个人的看法程序的OO是设计OO而不是数据的OO，你的前期设计按OO做出来以后，基本在数据库设计阶段的每一个对象都会对应一张数据表。没有必要一定要把数据搞的非常僵硬。早在3、4年钱就听说老外在做对象数据库，一直到现在连个影子都没有了。在对象数据库做垮以后就出了HIBERNATE这么个玩意，这东西好象有抄袭对象数据库的嫌疑曾经在CSDN上面看见关于版权的争论问题。从程序的效率来看，所谓ORM和SQL的效率根本不在一个级数上面，就更不谈存储过程了。开发效率也未见得就高到什么地方去，联表和缓寸的处理稍有不当就是比较郁闷的事情，还有个非常搞笑的问题在于它自己做出来的二级缓存却自己推荐不要使用。嘿嘿。。。看过HIEBERNAT的实现原理更喜欢IBATIS，更加灵活，效率更高。真正封装对象的本事不是来自己数据库，而是来自程序的设计。

Hibernate从来没有推荐过不使用二级缓存，相反，Hibernate是相当推荐使用二级缓存的。自己没用过，不要轻易盲目下结论，这不是做踏踏实实做技术的态度。

93 楼 xiaomeng 2007-05-25  

这天看了一下IBATIS和HIBERNATE的帖子，http://www.iteye.com/topic/41720。这个年代就是这样大家一说就是OO。传统的面向过程在现在开发中用起来有点吃力了，都改用了XP。随着时代的发展项目的工作量也越来越大，基本上告别单兵作战的年代。分工也越来越细，原有OO分析方法就用来描述更多的东西，连数据库也用OO来做了。
    我个人的看法程序的OO是设计OO而不是数据的OO，你的前期设计按OO做出来以后，基本在数据库设计阶段的每一个对象都会对应一张数据表。没有必要一定要把数据搞的非常僵硬。早在3、4年钱就听说老外在做对象数据库，一直到现在连个影子都没有了。在对象数据库做垮以后就出了HIBERNATE这么个玩意，这东西好象有抄袭对象数据库的嫌疑曾经在CSDN上面看见关于版权的争论问题。从程序的效率来看，所谓ORM和SQL的效率根本不在一个级数上面，就更不谈存储过程了。开发效率也未见得就高到什么地方去，联表和缓寸的处理稍有不当就是比较郁闷的事情，还有个非常搞笑的问题在于它自己做出来的二级缓存却自己推荐不要使用。嘿嘿。。。看过HIEBERNAT的实现原理更喜欢IBATIS，更加灵活，效率更高。真正封装对象的本事不是来自己数据库，而是来自程序的设计。

92 楼 lihy70 2007-04-28  

ltian 写道

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

用dbcoat, 它为你提供超越jdbc速度，尤其你要处理十万，百万和千万级别的数据时。
dbcoat提供jdbc一样批量数据插入，更新的操作，
dbcoat提供为大批量查询结果提供分段cache。
详细信息访问：
http://sourceforge.net/projects/dbcoat

91 楼 lihy70 2007-04-28  

mmwy 写道

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

开发效率和运行效率两者并没有逻辑冲突，
没做到，不代表不能做到。

90 楼 zhangzhaofeng 2007-04-27  

不趋向于具体那一种
看实际情况了