兔子压倒窝边草 2013-07-26
简介:本文主要讲述了iBatis2.x和MyBatis3.0.x的区别,以及从iBatis向MyBatis移植时需要注意的地方。通过对本文的学习,读者基本能够了解MyBatis有哪些方面的改进,并能够顺利使用MyBatis进行开发。本文更适合有iBatis基础的开发人员阅读。
从iBatis到MyBatis,你准备好了吗?
对于从事JavaEE的开发人员来说,iBatis是一个再熟悉不过的持久层框架了,在Hibernate、JPA这样的一站式对象/关系映射(O/RMapping)解决方案盛行之前,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主页上的一则“ApacheiBATIShasbeenretired”的声明在社区引起了一阵不小的波澜。在Apache寄居六年之后,iBatis将代码托管到GoogleCode。在声明中给出的主要理由是,和Apache相比,GoogleCode更有利于开发者的协同工作,也更能适应快速发布。于此同时,iBatis更名为MyBatis。
从iBatis到MyBatis,不只是名称上的变化,MyBatis提供了更为强大的功能,同时并没有损失其易用性,相反,在很多地方都借助于JDK的泛型和注解特性进行了简化。iBatis确实该退休了,因为一个更为出色的继任者经过10个Beta版本的蜕变已然出现在我们的面前。
本文将主要针对MyBatis和iBatis的变化之处进行讨论,以便于读者顺利从iBatis向MyBatis过渡。
回页首
由一个MyBatis示例开始
如果读者接触过一些常用的JavaEE框架,应该都知道这些框架需要提供一个全局配置文件,用于指定程序正常运行所需的设置和参数信息。而针对常用的持久层框架而言(Hibernate、JPA、iBatis等),则通常需要配置两类文件:一类用于指定数据源、事务属性以及其他一些参数配置信息(通常是一个独立的文件,可以称之为全局配置文件);另一类则用于指定数据库表和程序之间的映射信息(可能不止一个文件,我们称之为映射文件)。MyBatis也不例外,虽然其中的一部分可以通过注解的形式进行,但是这两部分内容本身仍是必不可少的。
根据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管理。
上面提及的大多数元素都不是必需的,通常MyBatis会为没有显式设置的元素提供缺省值。一个简单的全局配置文件示例如下:
清单1.简单的全局配置文件示例
<?xmlversion="1.0"encoding="UTF-8"?>
<!--iBatis和MyBatis的全局配置文件使用不同的DTD约束,在将应用由
iBatis升级至MyBatis时需要注意(两者的映射文件DTD约束也不相同)-->
<!DOCTYPEconfigurationPUBLIC"-//mybatis.org//DTDConfig3.0//EN"
"http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
<!--配置数据源相关的信息-->
<environmentsdefault="demo">
<environmentid="demo">
<transactionManagertype="JDBC"/>
<dataSourcetype="POOLED">
<propertyname="driver"value=…/>
<propertyname="url"value=…/>
<propertyname="username"value="root"/>
<propertyname="password"value="root"/>
</dataSource>
</environment>
</environments>
<!--列出映射文件-->
<mappers>
<mapperresource="footmark/mybatis/demo/UserInfoMapper.xml"/>
</mappers>
</configuration>
有了这些信息,MyBatis便能够和数据库建立连接,并应用给定的连接池信息和事务属性。MyBatis封装了这些操作,最终暴露一个SqlSessionFactory实例供开发者使用,从名字可以看出来,这是一个创建SqlSession的工厂类,通过SqlSession实例,开发者能够直接进行业务逻辑的操作,而不需要重复编写JDBC相关的样板代码。根据全局配置文件生成SqlSession的代码如下:
Readerreader=Resources.getResourceAsReader("Configuration.xml");
SqlSessionFactorysqlSessionFactory=
newSqlSessionFactoryBuilder().build(reader);
SqlSessionsqlSession=sqlSessionFactory.openSession();
可以把上面的三行代码看做是MyBatis创建SqlSession的样板代码。其中第一行代码在类路径上加载配置文件,Resources是MyBatis提供的一个工具类,它用于简化资源文件的加载,它可以访问各种路径的文件,不过最常用的还是示例中这种基于类路径的表示方式。如果读者对Hibernate有所了解,一定会发现MyBatis不论是使用风格还是类名都和Hibernate非常相像,笔者曾今多次在国内外Java社区看到有人说MyBatis在向Hibernate/JPA靠拢。暂且不论这是否属实,持久化技术在经过一番蓬勃的竞争和发展,最终在社区形成统一的认识并被广泛接受,这对开发者而言未必不是一件好事,MyBatis在这一点上只是向事实上的标准靠近了一步。
在完成全局配置文件,并通过MyBatis获得SqlSession对象之后,便可以执行数据访问操作了。对于iBatis/MyBatis而言,要执行的操作其实就是在映射文件中配置的SQL语句。两者的配置基本相同,如下所示:
清单2.在映射文件中配置SQL语句
<?xmlversion="1.0"encoding="UTF-8"?>
<!DOCTYPEmapperPUBLIC"-//mybatis.org//DTDMapper3.0//EN"
"http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mappernamespace="mybatis.demo.UserInfoMapper">
<selectid="selectUser"parameterType="int"
resultType="mybatis.demo.UserInfo">
select*fromUserInfowhereuserid=#{userid}
</select>
</mapper>
在iBatis中,namespace不是必需的,且它的存在没有实际的意义。在MyBatis中,namespace终于派上用场了,它使得映射文件与接口绑定变得非常自然。关于接口绑定,后面会有篇幅专门描述。使用SqlSession执行SQL的方式如下:
清单3.使用SqlSession执行映射文件中配置的SQL语句
try
{
UserInfouserinfo=(UserInfo)sqlSession.selectOne
("mybatis.demo.UserInfoMapper.getUser",2);
System.out.println(userinfo);
}finally
{
sqlSession.close();
}
需要注意的是,SqlSession的使用必需遵守上面的格式,即在finally块中将其关闭。以保证资源得到释放,防止出现内存泄露!
以上就是一个简单而完整的MyBatis程序。其中涉及了全局配置文件,映射文件,构建SqlSession对象,执行数据访问操作等四个步骤。下面将针对除构建SqlSession对象之外的三块内容进行分解。
回页首
MyBatis全局配置文件的改变
MyBatis全局配置文件的各主要元素基本和iBatis相同,只是在用法和个别名称上做了调整。元素的意义就不再描述,下面主要讲述针对iBatis和MyBatis配置文件的主要区别之处。
首先,两个版本的DTD约束不同,MyBatis的DTD文件已经包含在发布包下的mybatis-3.0.x.jar包中。这直接影响到的是,iBatis配置文件的根元素是<sqlMapConfig>,而MyBatis使用的是<configuration>。
其次,<settings>的用法发生了改变,之前的格式为:
清单4.在iBatis中设置属性的方式
<settingsprops1="value1"props2="value2"…/>
要设置的属性直接以键值对的形式作为<settings>的属性。而在MyBatis中调整为略显复杂但却更有条理的方式:
清单5.在MyBatis中设置属性的方式
<settings>
<settingname="props1"value="value1"/>
<settingname="props2"value="value2"/>
……
</settings>
另外,之前配置事务管理器和数据源的方式如下:
清单6.在iBatis中配置事务管理器和数据源的方式
<transactionManagertype="JDBC">
<dataSourcetype="SIMPLE">
<propertyname="JDBC.Driver"value="${driver}"/>
<!--其他数据源信息省略-->
</dataSource>
</transactionManager>
在MyBatis中调整为如下的方式:
清单7.在MyBatis中配置事务管理器和数据源的方式
<environmentsdefault="demo">
<environmentid="demo">
<transactionManagertype="JDBC"/>
<dataSourcetype="POOLED">
<propertyname="JDBC.Driver"value="${driver}"/>
<!--其他数据源信息省略-->
</dataSource>
</environment>
</environments>
通过<environments>来进行数据源管理,主要是为了简化在多套数据源配置之间的切换,比如开发和发布使用不同的配置。
最后,在iBatis中指定映射文件的方式如下:
清单8.在iBatis中指定映射文件的方式
<sqlMapresource=.../>
<sqlMapresource=.../>
<sqlMapresource=.../>
在MyBatis中调整为如下方式:
清单9.在MyBatis中指定映射文件的方式
<mappers>
<mapperresource=.../>
<mapperresource=.../>
</mappers>
上面的这些调整,主要出发点其实并不是使得MyBatis功能更为强大,而是使配置更为合理,让开发者更容易阅读和理解。
到目前为止,我们主要讨论了XML形式的全局配置,其实这也不是唯一选择,MyBatis还提供了通过代码来进行配置的方式:
清单10.在MyBatis中使用代码进行配置
DataSourceds=……//获取一个DataSource
TransactionFactorytxFactory=newJdbcTransactionFactory();
Environmentenv=newEnvironment("demo",txFactory,ds);
Configurationcfg=newConfiguration(env);
cfg.addMapper(UserInfoMapper.class);
SqlSessionFactorysqlSessionFactory=newSqlSessionFactoryBuilder().build(cfg);
结合前面的配置文件,很容易理解这段代码的意思,故不再赘述。不过,需要注意的是Configuration的addMapper()方法,该方法的参数通常是一个接口,可以在接口里面定义若干方法,在方法上使用注解来指定映射的SQL语句。一个典型的接口定义以及对应的数据访问方法如下:
清单11.将映射的SQL语句与接口中的方法绑定
//映射SQL绑定接口
publicinterfaceUserInfoMapper
{
@Select("select*fromuserinfowhereuserid=#{userid}")
publicUserInfogetUserInfo(intuserid);
}
//接口绑定对应的数据访问方法
try
{
//UserInfouserinfo=(UserInfo)sqlSession.selectOne
("mybatis.demo.UserInfoMapper.selectUser",2);
UserInfoMapperuserinfoMapper=
sqlSession.getMapper(UserInfoMapper.class);
UserInfouserinfo=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中调用存储过程的方式
<procedureid="getValues"parameterMap="getValuesPM">
{?=callpkgExample.getValues(p_id=>?)}
</procedure>
在MyBatis中,<proccedure>元素已经被移除,通过<select>、<insert>和<update>进行定义:
清单13.MyBatis中调用存储过程的方式
<selectid="getValues"parameterMap="getValuesPM"statementType="CALLABLE">
{?=callpkgExample.getValues(p_id=>?)}
</select>
如上所示,通过statementType属性将该语句标识为存储过程而非普通SQL语句。
回页首
代码层面的改变
通过前面的示例可以看出,MyBatis在编码中的最大的改变就是将一个最常用的API由SqlMapClient改为了SqlSessionFactory。另外,类型处理器接口也由原来的TypeHandlerCallback改为了TypeHandler。最后DataSourceFactory也进行了调整,移动到org.apache.ibatis.datasource包下,其中的方法也作了微调。总之,代码层面公开的部分改动较少,不会给开发者造成较大的移植成本。
回页首
总结
本文主要描述了从iBatis向MyBatis移植过程中可能遇到的问题,大部分的变化已经体现在上文中,如果希望从头开始学习MyBatis,则建议从头开始阅读官方的userguide文档。
如:对于sql语句order by #user_id#,如果传入的值是111,那么解析成sql时的值为order by "111", 如果传入的值是id,则解析成的sql为order by "id"。