ibatis MyBatis区别与联系

时间 2019-11-06

原文原文链接

简介： 本文主要讲述了 iBatis 2.x 和 MyBatis 3.0.x 的区别，以及从 iBatis 向 MyBatis 移植时须要注意的地方。经过对本文的学习，读者基本可以了解 MyBatis 有哪些方面的改进，并可以顺利使用 MyBatis 进行开发。本文更适合有 iBatis 基础的开发人员阅读。html

本文将主要针对 MyBatis 和 iBatis 的变化之处进行讨论，以便于读者顺利从 iBatis 向 MyBatis 过渡。java

由一个 MyBatis 示例开始

若是读者接触过一些经常使用的 Java EE 框架，应该都知道这些框架须要提供一个全局配置文件，用于指定程序正常运行所需的设置和参数信息。sql

而针对经常使用的持久层框架而言（Hibernate、JPA、iBatis 等），则一般须要配置两类文件：数据库

一类用于指定数据源、事务属性以及其余一些参数配置信息（一般是一个独立的文件，能够称之为全局配置文件）；
另外一类则用于指定数据库表和程序之间的映射信息（可能不止一个文件，咱们称之为映射文件）。

MyBatis 也不例外，虽然其中的一部分能够经过注解的形式进行，可是这两部份内容自己还是必不可少的。apache

根据 iBatis 的习惯，咱们一般把全局配置文件命名为 sqlMapConfig.xml，文件名自己并无要求，在 MyBatis 中，也常常会将该文件命名为 Configuration.xml （读彻底文后读者也许会发现，在 iBatis 中常常出现的 “sqlMap” 在 MyBatis 中被逐渐淡化了，除了此处，还好比 iBatis 配置文件的根元素为 <sqlMapConfig>，指定映射文件的元素为 <sqlMap>，以及 SqlMapClient 等等，这个变化正说明，iBatis 仅是以 SQL 映射为核心的框架，而在 MyBatis 中多以 Mapper、Session、Configuration 等其余经常使用 ORM 框架中的名字代替，体现的无非是两个方面：首先是为了减小开发者在切换框架所带来的学习成本；其次，MyBatis 充分吸取了其余 ORM 框架好的实践，MyBatis 如今已不只仅是一个 SQL 映射框架了）。在全局配置文件中能够配置的信息主要包括以下几个方面：mybatis

properties --- 用于提供一系列的键值对组成的属性信息，该属性信息能够用于整个配置文件中。

settings --- 用于设置 MyBatis 的运行时方式，好比是否启用延迟加载等。

typeAliases --- 为 Java 类型指定别名，能够在 XML 文件中用别名取代 Java 类的全限定名。

typeHandlers --- 在 MyBatis 经过 PreparedStatement 为占位符设置值，或者从 ResultSet 取出值时，特定类型的类型处理器会被执行。

objectFactory --- MyBatis 经过 ObjectFactory 来建立结果对象。能够经过继承 DefaultObjectFactory 来实现本身的 ObjectFactory 类。

plugins --- 用于配置一系列拦截器，用于拦截映射 SQL 语句的执行。能够经过实现 Interceptor 接口来实现本身的拦截器。

environments --- 用于配置数据源信息，包括链接池、事务属性等。

mappers --- 程序中全部用到的 SQL 映射文件都在这里列出，这些映射 SQL 都被 MyBatis 管理。

上面说起的大多数元素都不是必需的，一般 MyBatis 会为没有显式设置的元素提供缺省值。一个简单的全局配置文件示例以下：app

清单 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"> 
 <transactionManager type="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> 
 <mapper resource="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 得到 SqlSession 对象以后，即可以执行数据访问操做了。对于 iBatis/MyBatis 而言，要执行的操做其实就是在映射文件中配置的 SQL 语句。二者的配置基本相同，以下所示：

清单 2. 在映射文件中配置 SQL 语句

（Mybatis的）

<?xml version="1.0" encoding="UTF-8" ?> 
 <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
"http://mybatis.org/dtd/mybatis-3-mapper.dtd"> 
 <mapper namespace="mybatis.demo.UserInfoMapper"> 
 <select id="selectUser" parameterType="int"
 resultType="mybatis.demo.UserInfo"> 
 select * from UserInfo where userid =#{userid} 
 </select> 
 </mapper>

在 iBatis 中，namespace 不是必需的，且它的存在没有实际的意义。在 MyBatis 中，namespace 终于派上用场了，它使得映射文件与接口绑定变得很是天然。关于接口绑定，后面会有篇幅专门描述。使用 SqlSession 执行 SQL 的方式以下：

清单 3. 使用 SqlSession 执行映射文件中配置的 SQL 语句

try 
 { 
 UserInfo userinfo = (UserInfo) sqlSession.selectOne 
 ("mybatis.demo.UserInfoMapper.getUser", 2); 
 System.out.println(userinfo); 
 } finally 
 { 
 sqlSession.close(); 
 }

须要注意的是，SqlSession 的使用必需遵照上面的格式，即在 finally 块中将其关闭。以保证资源获得释放，防止出现内存泄露！

以上就是一个简单而完整的 MyBatis 程序。其中涉及了全局配置文件，映射文件，构建 SqlSession 对象，执行数据访问操做等四个步骤。下面将针对除构建 SqlSession 对象以外的三块内容进行分解。

上面说的是单独使用Mybatis, 通常Mybatis 整合Spring使用不用上面的API,使用更加简单方便。通常采用接口和Mapper文件映射。

回页首

MyBatis 全局配置文件的改变

MyBatis 全局配置文件的各主要元素基本和 iBatis 相同，只是在用法和个别名称上作了调整。元素的意义就再也不描述，下面主要讲述针对 iBatis 和 MyBatis 配置文件的主要区别之处。

首先，两个版本的 DTD 约束不一样，MyBatis 的 DTD 文件已经包含在发布包下的 mybatis-3.0.x.jar 包中。这直接影响到的是，iBatis 配置文件的根元素是 <sqlMapConfig>，而 MyBatis 使用的是 <configuration>。

其次，<settings> 的用法发生了改变，以前的格式为：

清单 4. 在 iBatis 中设置属性的方式

<settings props1="value1" props2="value2"… />

要设置的属性直接以键值对的形式做为 <settings> 的属性。而在 MyBatis 中调整为略显复杂但却更有条理的方式：

清单 5. 在 MyBatis 中设置属性的方式

<settings> 
 <setting name="props1" value="value1"/> 
 <setting name="props2" value="value2"/> 
……
 </settings>

另外，以前配置事务管理器和数据源的方式以下：

清单 6. 在 iBatis 中配置事务管理器和数据源的方式

<transactionManager type="JDBC" > 
 <dataSource type="SIMPLE"> 
 <property name="JDBC.Driver" value="${driver}"/> 
 <!-- 其余数据源信息省略 --> 
 </dataSource> 
 </transactionManager>

在 MyBatis 中调整为以下的方式：

清单 7. 在 MyBatis 中配置事务管理器和数据源的方式

<environments default="demo"> 
 <environment id="demo"> 
 <transactionManager type="JDBC"/> 
 <dataSource type="POOLED"> 
 <property name="JDBC.Driver" value="${driver}"/> 
 <!-- 其余数据源信息省略 --> 
 </dataSource> 
 </environment> 
 </environments>

经过 <environments> 来进行数据源管理，主要是为了简化在多套数据源配置之间的切换，好比开发和发布使用不一样的配置。

最后，在 iBatis 中指定映射文件的方式以下：

清单 8. 在 iBatis 中指定映射文件的方式

<sqlMap resource=... /> 
 <sqlMap resource=... /> 
 <sqlMap resource=... />

在 MyBatis 中调整为以下方式：

清单 9. 在 MyBatis 中指定映射文件的方式

<mappers> 
 <mapper resource=... /> 
 <mapper resource=... /> 
 </mappers>

其实配置开启包扫描就行不用这样配置

上面的这些调整，主要出发点其实并非使得 MyBatis 功能更为强大，而是使配置更为合理，让开发者更容易阅读和理解。

到目前为止，咱们主要讨论了 XML 形式的全局配置，其实这也不是惟一选择，MyBatis 还提供了经过代码来进行配置的方式：

清单 10. 在 MyBatis 中使用代码进行配置

DataSource ds = …… // 获取一个 DataSource 
 TransactionFactory txFactory = new JdbcTransactionFactory(); 
 Environment env = new Environment("demo", txFactory, ds); 
 Configuration cfg = new Configuration(env); 
 cfg.addMapper(UserInfoMapper.class); 
 SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(cfg);

结合前面的配置文件，很容易理解这段代码的意思，故再也不赘述。不过，须要注意的是 Configuration 的 addMapper() 方法，该方法的参数一般是一个接口，能够在接口里面定义若干方法，在方法上使用注解来指定映射的 SQL 语句。一个典型的接口定义以及对应的数据访问方法以下：

清单 11. 将映射的 SQL 语句与接口中的方法绑定

// 映射 SQL 绑定接口
 public interface UserInfoMapper 
 { 
 @Select("select * from userinfo where userid = #{userid}") 
 public UserInfo getUserInfo(int userid); 
 } 
 // 接口绑定对应的数据访问方法
 try 
 { 
 //UserInfo userinfo = (UserInfo) sqlSession.selectOne 
 ("mybatis.demo.UserInfoMapper.selectUser", 2); 
 UserInfoMapper userinfoMapper = 
 sqlSession.getMapper(UserInfoMapper.class); 
 UserInfo userinfo = userinfoMapper.getUserInfo(1); 
 System.out.println(userinfo); 
 } finally 
 { 
 sqlSession.close(); 
 }

回页首

MyBatis 映射文件的改变

MyBatis 针对映射文件进行格式调整的地方不少，但大部分仅仅只是名称上的变化，现代的 IDE 都支持联想功能，能够很方便的获取到当前位置能够有哪些元素、哪些属性等。因此这基本不会给开发者形成什么麻烦。

针对映射文件，首先是一系列的属性名称的改变，这些仅仅是名称的改变，用法和含义并无发生变化：

和全局配置文件同样，因为 DTD 约束发生变化，根元素也由原来的 <sqlMap> 调整为 <mapper>。

<select> 等元素的 parameterClass 属性改成了 parameterType 属性。

<select> 等元素的 resultClasss 属性改成了 resultType 属性。

<parameterMap> 等元素的 class 属性改成了 type 属性。

<result> 元素的 columnIndex 属性被移除了。

嵌套参数由 #value# 改成了 #{value}。

<parameter> 等元素的 jdbcType 属性取值中，原来的 "ORACLECURSOR" 取值改成了如今的 "CURSOR"，"NUMBER" 取值改成了 "NUMERIC"。

iBatis/MyBatis 对存储过程的支持一直是值得称道的。以前经过使用 <procedure> 元素进行存储过程的定义，示例以下：

清单 12. iBatis 中调用存储过程的方式

<procedure id="getValues" parameterMap="getValuesPM"> 
    { ? = call pkgExample.getValues(p_id => ?) } 
 </procedure>

在 MyBatis 中，<proccedure> 元素已经被移除，经过 <select>、<insert> 和 <update> 进行定义：

清单 13. MyBatis 中调用存储过程的方式

<select id="getValues" parameterMap="getValuesPM" statementType="CALLABLE"> 
    { ? = call pkgExample.getValues(p_id => ?)} 
 </select>

如上所示，经过 statementType 属性将该语句标识为存储过程而非普通 SQL 语句。

代码层面的改变

经过前面的示例能够看出，MyBatis 在编码中的最大的改变就是将一个最经常使用的 API 由 SqlMapClient 改成了 SqlSessionFactory。另外，类型处理器接口也由原来的 TypeHandlerCallback 改成了 TypeHandler。最后 DataSourceFactory 也进行了调整，移动到 org.apache.ibatis.datasource 包下，其中的方法也做了微调。总之，代码层面公开的部分改动较少，不会给开发者形成较大的移植成本。

来自:https://blog.csdn.net/techbirds_bao/article/details/9235309

作了写改动标注，为了我的学习。感谢原做者！