ibatis与hibernate的区别与适用范围

最大的区别在于：

ibatis只是方便你操作sql的。
hirbernate的目的是在代码中消除sql，在对象层实现持久化。

ibatas的sql语句需要自己手动写，而hibernate能够在程序运行时自动生成。但是不要就这样以为hibernate比ibatas方便，其实二者熟悉之后的效率差不多。而hibernate还能够自动建表等等，这样的好处就在于你带着这个程序，无论到什么机器上，你都不需要数据库，应为它能自动为你完成，而ibatas就必须要有相应的数据库表才能进行移植Hibernate的特点：Hibernate功能强大，数据库无关性好，O/R（对象/关系）映射能力强，如果你对Hibernate相当精通，而且对Hibernate进行了适当的封装，那么你的项目整个持久层代码会相当简单，需要写的代码很少，开发速度很快，非常爽。Hibernate对数据库结构提供了较为完整的封装，Hibernate的O/R Mapping实现了POJO（实体类） 和数据库表之间的映射，以及SQL 的自动生成和执行。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过Hibernate 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握， Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的SQL 并调用JDBC 接口加以执行。Hibernate的缺点就是学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡取得平衡，以及怎样用好Hibernate方面需要你的经验和能力都很强才行，但是Hibernate现在已经是主流O/R Mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于iBATIS。iBATIS的特点：iBATIS入门简单，即学即用，提供了数据库查询的自动对象绑定功能，而且延续了很好的SQL使用经验，对于没有那么高的对象模型要求的项目来说，相当完美。iBATIS的缺点就是框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。当系统属于二次开发,无法对数据库结构做到控制和修改,那iBATIS的灵活性将比Hibernate更适合。系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。在这种情况下iBATIS会有更好的可控性和表现。现在就市场来说，hibernate的需求要大于ibatas的需求，而hibernate对个人能力的要求更高，即使公司使用ibatas，你在hibernate的基础上也能快速掌握。

如果你sql编写的很好就用ibatis,好的sql可以提高查询效率,如果想快速开发就用hibernate,看项目需求

如果一个项目用Hibernate和Ibatis混合使用，

如果不得不混合使用，最好是一个功能用一个。一个处理中，避免同时用两个，否则会很痛苦。
整体来说，同时使用两种类似功能的时候，最头痛的是如何去管理，
因为这种无意义的混合，最容易受到其负面影响的是程序员，代码容易出现混乱，直接增加了出现bug的概率。

下面是百度百科的说法：

一站式

　　iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO），同时还提供一个利用这个框架开发的JPetStore实例。　　相对Hibernate和Apache OJB等“一站式”ORM解决方案而言，ibatis 是一种“半自动化”的ORM实现。

纵观目前主流

　　所谓“半自动”，可能理解上有点生涩。纵观目前主流的 ORM，无论 Hibernate 还是Apache OJB，都对数据库结构提供了较为完整的封装，提供了从POJO 到数据库表的全套映射机制。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过 Hibernate或者OJB 提供的方法完成持久层操作。程序员甚至不需要对 SQL 的熟练掌握，Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的 SQL 并调用 JDBC 接口加以执行。

新系统的开发

　　大多数情况下（特别是对新项目，新系统的开发而言），这样的机制无往不利，大有一统天下的势头。但是，在一些特定的环境下，这种一站式的解决方案却未必灵光。　　在笔者的系统咨询工作过程中，常常遇到以下情况： 　　1． 系统的部分或全部数据来自现有数据库，处于安全考虑，只对开发团队提供几条Select SQL（或存储过程）以获取所需数据，具体的表结构不予公开。 　　2． 开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由存储过程实现（就笔者工作所面向的金融行业而言，工商银行、中国银行、交通银行，都在开发规范中严格指定） 　　3． 系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。 　　面对这样的需求，再次举起 Hibernate 大刀，却发现刀锋不再锐利，甚至无法使用，奈何？恍惚之际，只好再摸出JDBC 准备拼死一搏……，说得未免有些凄凉，直接使用 JDBC进行数据库操作实际上也是不错的选择，只是拖沓的数据库访问代码，乏味的字段读取操作令人厌烦。

编辑本段半自动化

刚好解决

　　“半自动化”的ibatis，却刚好解决了这个问题。 　　这里的“半自动化”，是相对Hibernate等提供了全面的数据库封装机制的“全自动化”　　ORM 实现而言，“全自动”ORM 实现了 POJO 和数据库表之间的映射，以及 SQL 的自动　　生成和执行。而ibatis 的着力点，则在于POJO 与 SQL之间的映射关系。也就是说，ibatis　　并不会为程序员在运行期自动生成 SQL 执行。具体的 SQL 需要程序员编写，然后通过映　　射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定 POJO。　　通常在如下场景和条件下，选择ibatis, 将更有助于发挥ibatis在持久层的优越性：　　1. 知道怎样操作10种以上的数据库　　2. 可配置的caching(包括从属)　　3. 支持DataSource、local transaction managemen和global transaction　　4. 简单的XML配置文档　　5. 支持Map, Collection, List和简单类型包装(如Integer, String)　　6. 支持JavaBeans类(get/set 方法)　　7. 支持复杂的对象映射(如populating lists, complex object models)　　8. 对象模型从不完美(不需要修改)　　9. 数据模型从不完美(不需要修改)　　10. 你已经知道SQL，为什么还要学习其他东西

全自动

　　使用ibatis 提供的ORM机制，对业务逻辑实现人员而言，面对的是纯粹的 Java对象，　　这一层与通过 Hibernate 实现 ORM 而言基本一致，而对于具体的数据操作，Hibernate　　会自动生成SQL 语句，而ibatis 则要求开发者编写具体的 SQL 语句。相对Hibernate等　　“全自动”ORM机制而言，ibatis 以 SQL开发的工作量和数据库移植性上的让步，为系统　　设计提供了更大的自由空间。作为“全自动”ORM实现的一种有益补充，ibatis 的出现显　　得别具意义。

编辑本段发展

　　ibatis本是apache的一个开源项目，2010年这个项目由apache software foundation 迁移到了google code，并且改名为mybatis。