在 java 应用的数据库开发中，不可避免地会使用到持久层框架，而现在开源项目中持久层框架用到最多的基本就是 iBatis、myBatis 和 Hibernate 了。这里就重点分析下这三个框架之间的区别。

iBatis 与 Hibernate
iBatis 是基于SQL映射的持久层框架，相对 Hibernate 一站工的ORM解决框架来言，iBatis 算是一种半自动化的ORM实现。两者的区别是：
[list]
1.Hibernate 是当前最流行、最经典的o/r mapping框架；而 iBatis 相对 Hibernate“o/r”而言是一种“sql mapping”的orm实现。
2.iBatis入门简单，即学即用；而Hibernate则相对来说较为复杂，学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡取得平衡，怎样用好 Hibernate 方面需要经验和能力都很强才行。
3.对于具体的数据操作，Hibernate 会自动生成sql 语句，能够在程序运行时自动生成,能够自动建表，无论到什么机器上，都不需要数据库，都能自动完成迁移；而iBatis 则要求开发者编写具体的sql 语句，且必须要有相应的数据库表才能进行数据库的移植。相对 Hibernate 而言，iBatis 以sql开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。
4.Hibernate 功能强大，数据库无关性好，O/R（对象/关系）映射能力强,Hibernate 对数据库结构提供了较为完整的封装，Hibernate 的O/R Mapping实现了POJO（实体类） 和数据库表之间的映射，以及SQL 的自动生成和执行。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过 Hibernate 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握， Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的SQL 并调用JDBC 接口加以执行；而 iBatis 的着力点，则在于pojo与sql之间的映射关系。也就是说，iBatis 并不会为程序员在运行期自动生成sql 执行。具体的sql需要程序员编写，然后通过映射配置文件，将sql所需的参数，以及返回的结果字段映射到指定pojo。使用 iBatis 提供的orm机制，对业务逻辑实现人员而言，面对的是纯粹的java对象，缺点就是框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。如果涉及到数据库字段的修改，Hibernate 修改的地方很少，而 iBatis 要把那些sql mapping的地方一一修改。
5.当系统属于二次开发,无法对数据库结构做到控制和修改,那 iBatis 的灵活性将比 Hibernate 更适合。系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。在这种情况下 iBatis 会有更好的可控性和表现。
6.Hibernate 现在已经是主流O/R Mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于iBatis。
[/list]

iBatis与myBatis
iBatis是2002年发起的开放源代码项目，之前一直托管在apache下，于2010年6月16号被谷歌托管，改名为MyBatis，myBatis 与 iBatis 一样，也是一种“半自动化”的ORM实现，共同的优点：
[list]
1.是一个基于Java的持久层框架
2.提供的持久层框架包括SQL Maps和Data Access Objects（DAO）
3.支持普通 SQL查询，存储过程和高级映射的优秀持久层框架
4.消除了几乎所有的JDBC代码和参数的手工设置以及结果集的检索
5.使用简单的 XML或注解用于配置和原始映射，将接口和 Java 的POJOs（Plain Old Java Objects，普通的 Java对象）映射成数据库中的记录
[/list]
总体流程：
[list]
1.加载配置并初始化
2.接收调用请求
3.处理操作请求
4.返回处理结果将最终的处理结果返回
[/list]
功能架构：
[list]
1.API接口层：提供给外部使用的接口API，开发人员通过这些本地API来操纵数据库。接口层一接收到调用请求就会调用数据处理层来完成具体的数据处理。
2.数据处理层：负责具体的SQL查找、SQL解析、SQL执行和执行结果映射处理等。它主要的目的是根据调用的请求完成一次数据库操作。
3.基础支撑层：负责最基础的功能支撑，包括连接管理、事务管理、配置加载和缓存处理，这些都是共用的东西，将他们抽取出来作为最基础的组件。为上层的数据处理层提供最基础的支撑。
[/list]
当然，iBatis 改名为 myBatis 后，进行了一部分的改良，myBatis 在很多地方都借助于 JDK 的泛型和注解特性进行了简化，他们的主要区别是：
[list]
1.mybatis 实现了接口绑定，使用更加方便。在 iBatis 中我们需要在DAO的实现类中指定具体对应哪个xml映射文件。简单地讲，就是 myBatis 不需要写DAO接口的实现类了，已经自动实现了接口与xml映射文件的对应。
2.对象关系映射的改进，效率更高。myBatis中，除了兼容 iBatis2.x 中的“嵌套查询”方式外，还提供了直接“嵌套结果”的方式，其效果相当于直接通过一句sql将查询出的dto对象自动封装成所需的对象，但这一方式在使用分页的时候并不起作用，或者说嵌套对象的结果集是不允许进行分页的。
3.个别配置的方法更改。iBatis 习惯把全局配置文件命名为 sqlMapConfig.xml， myBatis 将该文件命名为 Configuration.xml 。iBatis 仅是以 SQL 映射为核心的框架，而在 myBatis 中多以 Mapper、Session、Configuration 等其他常用 ORM 框架中的名字代替，体现的无非是两个方面：首先是为了减少开发者在切换框架所带来的学习成本；其次，myBatis 充分吸收了其他 ORM 框架好的实践，myBatis 现在已不仅仅是一个 SQL 映射框架了。在 iBatis 中，namespace 不是必需的，且它的存在没有实际的意义。在 myBatis 中，namespace 终于派上用场了，它使得映射文件与接口绑定变得非常自然。
4.myBatis 采用功能强大的基于OGNL的表达式来消除其他元素。
[/list]