hibernate vs ibatis
IBATIS:
iBATIS一词来源于“internet”和“abatis”的组合，是一个由ClintonBegin在2001年发起的开放源代码项目，最初侧重于密码软件的开发，现在是一个基于Java的持久层框架。
iBATIS提供的持久层框架包括SQLMaps和DataAccessObjects（DAO），同时还提供一个利用这个框架开发的JPetStore实例，相对Hibernate和ApacheOJB等“一站式”ORM解决方案而言，ibatis是一种“半自动化”的ORM实现，iBATIS需要开发人员自己来写sql语句，这可以增加了程序的灵活性，在一定程度上可以作为ORM的一种补充，程序设计人员应该结合自己的项目的实际情况，来选择使用不同的策略。
iBATIS和Hibernate都做了映射，但iBATIS是把实体类和sql语句之间建立了映射关系，这种策略可以允许开发人员自己来写合适的sql语句，而Hibernate在实体类和数据库之间建立了映射关系，sql对于开发人员是不可见的，对于那些数据量非常大的应用，无法去优化sql语句。
所谓“半自动”，可能理解上有点生涩,纵观目前主流的ORM，无论Hibernate还是ApacheOJB，都对数据库结构提供了较为完整的封装，提供了从POJO到数据库表的全套映射机制,程序员往往只需定义好了POJO到数据库表的映射关系，即可通过Hibernate或者OJB提供的方法完成持久层操作,程序员甚至不需要对SQL的熟练掌握，Hibernate/OJB会根据制定的存储逻辑，自动生成对应的SQL并调用JDBC接口加以执行。
HIBERNATE:
Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库.
Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序使用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任.
Hibernate是一个免费的开源Java包，它使得与关系数据库打交道变得十分轻松，就像您的数据库中包含每天使用的普通Java对象一样，同时不必考虑如何把它们从神秘的数据库表中取出（或放回到数据库表中）
IBATIS和HIBERNATE的比较：
在系统咨询工作过程中，常常遇到以下情况：
1．系统的部分或全部数据来自现有数据库，处于安全考虑，只对开发团队提供几条SelectSQL（或存储过程）以获取所需数据，具体的表结构不予公开
2．开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由存储过程实现（就笔者工作所面向的金融行业而言，工商银行、中国银行、交通银行，都在开发规范中严格指定）
3．系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标，面对这样的需求，再次举起Hibernate大刀，却发现刀锋不再锐利，甚至无法使用，奈何？恍惚之际，只好再摸出JDBC准备拼死一搏……，说得未免有些凄凉，直接使用JDBC进行数据库操作实际上也是不错的选择，只是拖沓的数据库访问代码，乏味的字段读取操作令人厌烦，“半自动化”的ibatis，却刚好解决了这个问题，这里的“半自动化”，是相对Hibernate等提供了全面的数据库封装机制的“全自动化”，ORM实现而言，“全自动”ORM实现了POJO和数据库表之间的映射，以及SQL的自动生成和执行，而ibatis的着力点，则在于POJO与SQL之间的映射关系，也就是说，ibatis并不会为程序员在运行期自动生成SQL执行，具体的SQL需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。
使用ibatis提供的ORM机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate实现ORM而言基本一致，而对于具体的数据操作，Hibernate会自动生成SQL语句，而ibatis则要求开发者编写具体的SQL语句，相对Hibernate等“全自动”ORM机制而言，ibatis以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间，作为“全自动”ORM实现的一种有益补充，ibatis的出现显得别具意义。
IBATIS的优势：
1.iBatis易于掌握。拿来文档看半天到两天就可以掌握了。
Hibernate可能需要3倍以上的时间来掌握。
2.iBatis更容易进行sql的优化。
这个应该大家都有共识了。另外Hibernate生成的sql也实在是太难看了。鉴于有的朋友提到了sql不太重要。我想在这里强调一下我的经验，一般系统性能的瓶颈都在数据库上。所以这一点是iBatis非常重要的一个优势。
3.iBatis可以进行细粒度的优化
3.1比如说我有一个表，这个表有几个或者几十个字段，我需要更新其中的一个字段，iBatis很简单，执行一个sql
UPDATETABLE_ASETcolumn_1=#column_1#WHEREid=#id#但是用Hibernate的话就比较麻烦了,缺省的情况下hibernate会更新所有字段。当然我记得hibernate有一个选项可以控制只保存修改过的字段，但是我不太确定这个功能的负面效果。
3.2我需要列出一个表的部分内容，用iBatis的时候，这里面的好处是可以少从数据库读很多数据，节省流量SELECTID,NAMEFROMTABLE_WITH_A_LOT_OF_COLUMNWHERE…
3.2.1一般情况下，Hibernate会把所有的字段都选出来。比如说有一个上面表有8个字段，其中有一两个比较大的字段，varchar(255)/text。上面的场景中我为什么要把他们也选出来呢？
3.2.2用hibernate的话，你又不能把这两个不需要的字段设置为lazyload，因为还有很多地方需要一次把整个domainobject加载出来。这个时候就能显现出ibatis的好处了
3.2.3Hibernate还有一个方案，就是生成javabean/map/object[]，但是这样的话就可能会产生大量的多余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。
在实际应用中，应该根据不同的应用场景，来选择适合自己的框架。