数据库持久层框架iBatis、myBatis、Hibernate对比
在java应用的数据库开发中，不可避免地会使用到持久层框架，而现在开源项目中持久层框架用到最多的基本就是iBatis、myBatis和Hibernate了。这里就重点分析下这三个框架之间的区别。
iBatis与Hibernate
iBatis是基于SQL映射的持久层框架，相对Hibernate一站工的ORM解决框架来言，iBatis算是一种半自动化的ORM实现。两者的区别是：
1.Hibernate是当前最流行、最经典的o/rmapping框架；而iBatis相对Hibernate“o/r”而言是一种“sqlmapping”的orm实现。
2.iBatis入门简单，即学即用；而Hibernate则相对来说较为复杂，学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡取得平衡，怎样用好Hibernate方面需要经验和能力都很强才行。
3.对于具体的数据操作，Hibernate会自动生成sql语句，能够在程序运行时自动生成,能够自动建表，无论到什么机器上，都不需要数据库，都能自动完成迁移；而iBatis则要求开发者编写具体的sql语句，且必须要有相应的数据库表才能进行数据库的移植。相对Hibernate而言，iBatis以sql开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。
4.Hibernate功能强大，数据库无关性好，O/R（对象/关系）映射能力强,Hibernate对数据库结构提供了较为完整的封装，Hibernate的O/RMapping实现了POJO（实体类）和数据库表之间的映射，以及SQL的自动生成和执行。程序员往往只需定义好了POJO到数据库表的映射关系，即可通过Hibernate提供的方法完成持久层操作。程序员甚至不需要对SQL的熟练掌握，Hibernate/OJB会根据制定的存储逻辑，自动生成对应的SQL并调用JDBC接口加以执行；而iBatis的着力点，则在于pojo与sql之间的映射关系。也就是说，iBatis并不会为程序员在运行期自动生成sql执行。具体的sql需要程序员编写，然后通过映射配置文件，将sql所需的参数，以及返回的结果字段映射到指定pojo。使用iBatis提供的orm机制，对业务逻辑实现人员而言，面对的是纯粹的java对象，缺点就是框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。如果涉及到数据库字段的修改，Hibernate修改的地方很少，而iBatis要把那些sqlmapping的地方一一修改。
5.当系统属于二次开发,无法对数据库结构做到控制和修改,那iBatis的灵活性将比Hibernate更适合。系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。在这种情况下iBatis会有更好的可控性和表现。
6.Hibernate现在已经是主流O/RMapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于iBatis。
iBatis与myBatis
iBatis是2002年发起的开放源代码项目，之前一直托管在apache下，于2010年6月16号被谷歌托管，改名为MyBatis，myBatis与iBatis一样，也是一种“半自动化”的ORM实现，共同的优点：
1.是一个基于Java的持久层框架
2.提供的持久层框架包括SQLMaps和DataAccessObjects（DAO）
3.支持普通SQL查询，存储过程和高级映射的优秀持久层框架
4.消除了几乎所有的JDBC代码和参数的手工设置以及结果集的检索
5.使用简单的XML或注解用于配置和原始映射，将接口和Java的POJOs（PlainOldJavaObjects，普通的Java对象）映射成数据库中的记录
总体流程：
1.加载配置并初始化
2.接收调用请求
3.处理操作请求
4.返回处理结果将最终的处理结果返回
功能架构：
1.API接口层：提供给外部使用的接口API，开发人员通过这些本地API来操纵数据库。接口层一接收到调用请求就会调用数据处理层来完成具体的数据处理。
2.数据处理层：负责具体的SQL查找、SQL解析、SQL执行和执行结果映射处理等。它主要的目的是根据调用的请求完成一次数据库操作。
3.基础支撑层：负责最基础的功能支撑，包括连接管理、事务管理、配置加载和缓存处理，这些都是共用的东西，将他们抽取出来作为最基础的组件。为上层的数据处理层提供最基础的支撑。
当然，iBatis改名为myBatis后，进行了一部分的改良，myBatis在很多地方都借助于JDK的泛型和注解特性进行了简化，他们的主要区别是：
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的表达式来消除其他元素。