程序开发中Hibernate和Ibatis的选择

    今天之天下，Hibernate横行其道，程序员们见其霸道无比，纷纷投靠。场面是壮烈恢宏。Hibernate流行有它的道理，纯粹的面向对象思想给你提供了从POJO到关系数据库的完全映射，从此对一切对数据库的操作都变成了简单的几个方法。世界好像从此清静了。映射这方面Hibernate是功成名就，是自豪的。Ibatis更是被Hibernate远远抛在后面。
    在使用上，在Hibernate这里，好像一切都成了对象，这多好，程序员可以更好的发挥对象，更好应用面向对象的思想。其不知面向对象也有它自己的缺点。所以Hibernate这把左轮SHOUQIANG也会有没有子弹的时候。

1． 系统的部分或全部数据来自现有数据库，处于安全考虑，只对开发团队提供几条Select SQL（或存储过程）以获取所需数据，具体的表结构不予公开。
2． 开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由存储过程实现
3． 系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。
总上所述，Hibernate之所以会没有子弹是因为数据库的要求出了问题，数据库不公开，要求尽可能的利用存储过程，数据量大，苛刻的性能要求等等都是因为数据库。由此可见Hibernate在封装对象的同时也牺牲了SQL的灵活性。这时Ibatis这匹刚吃完草的马儿是整装上阵，蓄意待发！以上问题被Ibatis拉的远远的，通通解决。Ibatis在SQL上的灵活性是众所周知。 Hibernate和Ibatis的用力点不一样，前者尽最大努力封装SQL，后尽最大努力灵活SQL。
   在易用性上面，iBatis 易于掌握。拿来文档看半天到两天就可以掌握了。Hibernate 可能需要 3 倍以上的时间来掌握。岂止是3倍，Hibernate的O/R设计及缓存机制的合理应用可不是轻易能上手的，是要靠不断应用经验才能熬的出来。所以不弄几个项目出来真不敢说会用Hibernate。
   性能上，这可能是大家最想知道的，也是大家经常辩论的。Hibernate用HQL+缓存机制+延迟加载真能比的上直接写的SQL。遇见大数据量情况时Hibernate的优化方案还能拿的起，放的下吗？答案好像从来没有确定过。因为这牵涉到很的问题，数据库的表设计，Hibernate的缓存设计等等。Hibernate和Ibatis性能没有高低关键在于设计。
   存在就有它存在的道理，Hibernate和Ibatis都存在，但并一定是为我们的项目而存在，要选择谁还要靠实际情况！