论坛首页 入门技术论坛

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

浏览 69630 次
该帖已经被评为新手帖
作者 正文
   发表时间:2006-12-30  
[注意]清在回复之前认真地看一下我的帖子,结合你的实际项目经验考虑一下,看看你是否能比较好地解决我所提出的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 的代码。欢迎大家一起来讨论。
  

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

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

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

当然了,我对 Hibernate 的理解还是非常有限的,所以这里的关于 Hibernate 的一些观
点的错误之处希望能够得到 Hibernate 高手的指正。


1. iBatis 易于掌握。拿来文档看半天到两天就可以掌握了。
   Hibernate 可能需要 3 倍以上的时间来掌握。
  
   其中有一些与我探讨的人跟我说 Hibernate 也很容易学,但是在与他们的更深一步的
   讨论中,我发现他们只是使用了 Hibernate 最简单的一部分功能,更深一些的功能,
   和我提出来的一些疑虑他们并没有考虑到。

2. iBatis 更容易进行 sql 的 优化。

   这个应该大家都有共识了。另外 Hibernate 生成的 sql 也实在是太难看了。
  
3. iBatis 可以进行细粒度的优化

   3.1 比如说我有一个表,我需要更新其中的一个字段,iBatis 很简单,执行一个sql
       UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#
       但是用 Hibernate 的话就比较麻烦了
      
   3.2 我需要列出一个表的部分内容,用 iBatis 的时候,这里面的好处是可以少从数据
     库读很多数据,节省流量
       SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...
      
      
      
当然 iBatis 也有比较大的缺点
1. 不同数据库类型的支持不好
2. 缺省的 cache 支持不好
      
  

  



看了偶即使闲极无聊也没必要去看一下iBatis了
0 请登录后投票
   发表时间:2006-12-30  
就我的理解,iBATIS不是一个ORM工具,哪有什么可比的地方。
只是一个sql mapping tool。

感觉这一种VS没有什么意思
0 请登录后投票
   发表时间:2006-12-30  
以上列出来的几条并不是两者绝对存在的差异,其实运用得好Hibernate,上面的问题都不是问题……

而如果使用者水平有限的话,上述iBatis的“优点”也就没有意义了。

这个帖子的标题要是写作 —— “作为JDBC高手的我为什么选择 iBatis 而不是 Hibernate”就更加贴切了。
0 请登录后投票
   发表时间:2006-12-30  
jiming 写道

1. iBatis 易于掌握。拿来文档看半天到两天就可以掌握了。
   Hibernate 可能需要 3 倍以上的时间来掌握。
  
   其中有一些与我探讨的人跟我说 Hibernate 也很容易学,但是在与他们的更深一步的
   讨论中,我发现他们只是使用了 Hibernate 最简单的一部分功能,更深一些的功能,
   和我提出来的一些疑虑他们并没有考虑到。

2. iBatis 更容易进行 sql 的 优化。

   这个应该大家都有共识了。另外 Hibernate 生成的 sql 也实在是太难看了。
  
3. iBatis 可以进行细粒度的优化

   3.1 比如说我有一个表,我需要更新其中的一个字段,iBatis 很简单,执行一个sql
       UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#
       但是用 Hibernate 的话就比较麻烦了
      
   3.2 我需要列出一个表的部分内容,用 iBatis 的时候,这里面的好处是可以少从数据
     库读很多数据,节省流量
       SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...
      
当然 iBatis 也有比较大的缺点
1. 不同数据库类型的支持不好
2. 缺省的 cache 支持不好   
  

虽然不是hibernate高手,也想来替它平反一下:
1:Hibernate 可能需要 3 倍以上的时间来掌握,但它也能成倍提高效率;
2:sql难看就难看呗,基本不需要看了
3.1:hibernate load出一个对象,修改,然后保存就可以。hibernate还可以通过p6spy优化性能
3.2:hibernate的延迟加载会更节省流量

另外, iBatis 的第一个缺点——不同数据库类型的支持不好,足以让它输给hibernate了吧
0 请登录后投票
   发表时间:2006-12-30  
我觉得楼主应该没有用过hibernate吧,lz并没有写hibernate的优点,而是一个劲的写缺点,ibatis和hibernate其实应该可以看成是互不的两个东西,hibernate学习成本高于ibatis,但是hibernate的效率也高于ibatis,用hibernate也更oo,我看到lz说ibatis更容易优化芸芸,其实一般的系统要优化的sql语句有多少??一般的项目用hibernate是没有问题的,遗留系统或者性能要求非常苛刻的系统应该用ibatis,这两者没有绝对的好和坏的问题,只有不同的系统不同的项目用哪个更合适的问题,如果lz说hibernate不适合你们的系统,那请讲讲理由好吗
0 请登录后投票
   发表时间:2006-12-30  
最近正在看Hibernate,感觉要深入了解确实需要较多时间,特别是用好它的缓存策略!

虽然ibatis不是ORM,但是它们的共同点都是解决数据持久层的问题,在一起比较也不为过吧.
0 请登录后投票
   发表时间:2006-12-30  
http://robbin.iteye.com/blog/24529
0 请登录后投票
   发表时间:2006-12-30  
我选择用iBatis,主要是可以照搬JPetStore的架构
而且,写的SQL语句,基本可以直接拿到数据库上去执行测试。
0 请登录后投票
   发表时间:2006-12-30  
ahuaxuan 写道
我觉得楼主应该没有用过hibernate吧,lz并没有写hibernate的优点,而是一个劲的写缺点,ibatis和hibernate其实应该可以看成是互不的两个东西,hibernate学习成本高于ibatis,但是hibernate的效率也高于ibatis,用hibernate也更oo,我看到lz说ibatis更容易优化芸芸,其实一般的系统要优化的sql语句有多少??一般的项目用hibernate是没有问题的,遗留系统或者性能要求非常苛刻的系统应该用ibatis,这两者没有绝对的好和坏的问题,只有不同的系统不同的项目用哪个更合适的问题,如果lz说hibernate不适合你们的系统,那请讲讲理由好吗

hibernate的效率高于iBATIS?请讲讲理由。
0 请登录后投票
论坛首页 入门技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics