首页 > 代码库 > Mybatis与Ibatis比较

Mybatis与Ibatis比较

2024-11-24 05:06:39   202人阅读

        随着开发团队转投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 映射框架了）

 

在全局配置文件中可以配置的信息主要包括如下几个方面：

  • properties ---用于提供一系列的键值对组成的属性信息，该属性信息可以用于整个配置文件中。
  • settings ---用于设置 MyBatis的运行时方式，比如是否启用延迟加载等。
  • typeAliases ---为 Java类型指定别名，可以在 XML文件中用别名取代 Java类的全限定名。
  • typeHandlers ---在 MyBatis通过 PreparedStatement为占位符设置值，或者从 ResultSet取出值时，特定类型的类型处理器会被执行。
  • objectFactory --- MyBatis通过 ObjectFactory来创建结果对象。可以通过继承 DefaultObjectFactory来实现自己的 ObjectFactory类。
  • plugins ---用于配置一系列拦截器，用于拦截映射 SQL语句的执行。可以通过实现 Interceptor接口来实现自己的拦截器。
  • environments ---用于配置数据源信息，包括连接池、事务属性等。
  • mappers ---程序中所有用到的 SQL映射文件都在这里列出，这些映射 SQL都被 MyBatis管理。

 

清单 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= http://www.mamicode.com/…/>>
 
       有了这些信息，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在这一点上只是向事实上的标准靠近了一步。
Mybatis与Ibatis比较


联系
我们