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

这天看了一下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，也不喜欢所谓的OO，大家可以冷静的想想，有多少系统是真正使用的 OO 方式来设计和实现的呢？

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

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

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

  
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 就可以了。减少一次与数据库的交互，对于性能的
     提升是非常重要。

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