随着开发团队转投GoogleCode旗下，ibatis3.x正式更名为Mybatis
对于从事 Java EE 的开发人员来说，iBatis 是一个再熟悉不过的持久层框架了，在Hibernate、JPA 这样的一站式对象 / 关系映射（O/R Mapping）解决方案盛行之前，iBaits基本是持久层框架的不二选择。即使在持久层框架层出不穷的今天，iBatis 凭借着易学易用、轻巧灵活等特点，也仍然拥有一席之地。尤其对于擅长 SQL的开发人员来说，iBatis 对 SQL 和存储过程的直接支持能够让他们在获得 iBatis 封装优势的同时而不丧失 SQL 调优的手段，这是 Hibernate/JPA所无法比拟的。具体而言，使用 iBatis 框架的主要优势主要体现在如下几个方面：
首先，iBatis 封装了绝大多数的 JDBC 样板代码，使得开发者只需关注 SQL本身，而不需要花费精力去处理例如注册驱动，创建 Connection，以及确保关闭 Connection 这样繁杂的代码。
其次，iBatis可以算是在所有主流的持久层框架中学习成本最低，最容易上手和掌握的框架。虽说其他持久层框架也号称门槛低，容易上手，但是等到你真正使用时会发现，要想掌握并用好它是一件非常困难的事。在工作中我需要经常参与面试，我曾听到过很多位应聘者描述，他们所在的项目在技术选型时选择Hibernate，后来发现难以驾驭，不得不将代码用 JDBC 或者 iBatis 改写。
iBatis 自从在 Apache 软件基金会网站上发布至今，和他的明星兄弟们（HttpServer，Tomcat，Struts，Maven，Ant 等等）一起接受者万千 Java 开发者的敬仰。然而在今年六月中旬，几乎是发布 3.0版本的同时，iBatis 主页上的一则 “Apache iBATIS has been retired” 的声明在社区引起了一阵不小的波澜。在 Apache寄居六年之后，iBatis 将代码托管到 Google Code。在声明中给出的主要理由是，和 Apache 相比，Google Code更有利于开发者的协同工作，也更能适应快速发布。于此同时，iBatis 更名为 MyBatis。
从 iBatis 到 MyBatis，不只是名称上的变化，MyBatis 提供了更为强大的功能，同时并没有损失其易用性，相反，在很多地方都借助于JDK 的泛型和注解特性进行了简化。iBatis 确实该退休了，因为一个更为出色的继任者经过 10 个 Beta 版本的蜕变已然出现在我们的面前。
两者的具体变化让我们细细说来：
一、全局配置文件：
根据 iBatis 的习惯，我们通常把全局配置文件命名为sqlMapConfig.xml，文件名本身并没有要求，在 MyBatis 中，也经常会将该文件命名为 Configuration.xml（读完全文后读者也许会发现，在 iBatis 中经常出现的 “sqlMap” 在 MyBatis 中被逐渐淡化了，除了此处，还比如 iBatis配置文件的根元素为 <sqlMapConfig>，指定映射文件的元素为 <sqlMap>，以及 SqlMapClient等等，这个变化正说明，iBatis 仅是以 SQL 映射为核心的框架，而在 MyBatis 中多以 Mapper、Session、Configuration等其他常用 ORM 框架中的名字代替，体现的无非是两个方面：首先是为了减少开发者在切换框架所带来的学习成本；其次，MyBatis 充分吸收了其他 ORM框架好的实践，MyBatis 现在已不仅仅是一个 SQL 映射框架了）
在全局配置文件中可以配置的信息主要包括如下几个方面：
清单 1.简单的全局配置文件示例
<?xml version="1.0"encoding="UTF-8" ?> <!--iBatis 和 MyBatis 的全局配置文件使用不同的 DTD约束，在将应用由 iBatis 升级至 MyBatis 时需要注意（两者的映射文件 DTD约束也不相同）--> <!DOCTYPE configuration PUBLIC"-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd"> <configuration> <!-- 配置数据源相关的信息 --> <environments default="demo"> <environment id="demo"> <transactionManagertype="JDBC"/> <dataSource type="POOLED"> <property name="driver" value= …/> <property name="url" value= …/> <property name="username"value="root"/> <property name="password"value="root"/> </dataSource> </environment> </environments> <!-- 列出映射文件 --> <mappers> <mapperresource="footmark/mybatis/demo/UserInfoMapper.xml"/> </mappers> </configuration>
有了这些信息，MyBatis便能够和数据库建立连接，并应用给定的连接池信息和事务属性。MyBatis 封装了这些操作，最终暴露一个 SqlSessionFactory实例供开发者使用，从名字可以看出来，这是一个创建 SqlSession 的工厂类，通过 SqlSession实例，开发者能够直接进行业务逻辑的操作，而不需要重复编写 JDBC 相关的样板代码。根据全局配置文件生成 SqlSession 的代码如下：
Reader reader =Resources.getResourceAsReader("Configuration.xml");
SqlSessionFactory sqlSessionFactory =
new SqlSessionFactoryBuilder().build(reader);
SqlSession sqlSession =sqlSessionFactory.openSession();
可以把上面的三行代码看做是 MyBatis 创建SqlSession 的样板代码。其中第一行代码在类路径上加载配置文件，Resources 是 MyBatis提供的一个工具类，它用于简化资源文件的加载，它可以访问各种路径的文件，不过最常用的还是示例中这种基于类路径的表示方式。
二、Mybatis实现了接口绑定，使用更加方便。
在ibatis2.x中我们需要在DAO的实现类中指定具体对应哪个xml映射文件，
而Mybatis实现了DAO接口与xml映射文件的绑定，自动为我们生成接口的具体实现，使用起来变得更加省事和方便。这可以说是Mybatis最重要的改进。
注意：
虽然Mybatis支持在接口中直接使用annotation的配置方式来简化配置，不过强烈建议仍然使用xml配置的方式。毕竟annotation的配置方式功能有限且代码入侵性太强。使用xml配置方式才能体现出Mybatis的优势所在。
三、MyBatis采用功能强大的基于OGNL的表达式来消除其他元素。
熟悉struts2的人应该对OGNL表达式不会感到陌生，MyBatis采用OGNL表达式简化了配置文件的复杂性，使用起来更简洁。
四、动态sql
在配置动态sql语句方面，mybatis中使用的标签与iBATIS中使用的标签有很大的不同。这里不再举例。但这往往是你从iBATIS迁移到mybatis的过程中最为巨大的工作量。
五、。。。。。
mybatis与iBATIS可以说有很多地方相同，但却是有很多细节上的不同这里就不一一列出了。还是希望读者在具体的实战中发掘。如果你原来没有接触过iBATIS，那你完全可以直接学习mybatis了。因为mybatis确实是在iBATIS上的改进与发展。
总结：
如果读者对 Hibernate有所了解，一定会发现 MyBatis 不论是使用风格还是类名都和 Hibernate 非常相像，笔者曾今多次在国内外 Java 社区看到有人说 MyBatis在向 Hibernate/JPA靠拢。暂且不论这是否属实，持久化技术在经过一番蓬勃的竞争和发展，最终在社区形成统一的认识并被广泛接受，这对开发者而言未必不是一件好事，MyBatis在这一点上只是向事实上的标准靠近了一步。
原文地址：http://blog.csdn.net/hy6688_/article/details/43342177
