(经典)从Ibatis过渡到Mybatis-比较Mybaits较与Ibatis有哪些方面的改进
(经典)从Ibatis过度到Mybatis---比较Mybaits较与Ibatis有哪些方面的改进
随着开发团队转投Google Code旗下,ibatis3.x正式更名为Mybatis。那么mybatis较于ibatis做了哪些方面的突破呢?这里我总结些:(不一定完整,是本人整理总结的)
1.全局文件的配置:
MyBatis 全局配置文件的各主要元素基本和 iBatis 相同,只是在用法和个别名称上做了调整。元素的意义就不再描述,下面主要讲述针对 iBatis 和 MyBatis 配置文件的主要区别之处。
1.1,两个版本的 DTD 约束不同,MyBatis 的 DTD 文件已经包含在发布包下的 mybatis-3.0.x.jar 包中。这直接影响到的是,iBatis 配置文件的根元素是
有了这些信息,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现在已经没有SqlMapClient了,使用的则是SqlSession.在原来的基础上加了像selectMap,selectList,selectOne这样的方法,使用更方便了。)
1.2,之前ibatis配置事务管理器和数据源的方式如下:
在 MyBatis 中配置事务管理器和数据源的方式:
1.3,在 iBatis 中指定映射文件的方式如下:
在 MyBatis 中指定映射文件的方式:
附:到目前为止,我们主要讨论了 XML 形式的全局配置,其实这也不是唯一选择,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 语句。
// 映射 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(); }
2.映射文件中配置 SQL 语句:
在 iBatis 中,namespace 不是必需的,且它的存在没有实际的意义。在 MyBatis 中,namespace 终于派上用场了,它使得映射文件与接口绑定变得非常自然。Ibatis用的parameterClass在mybatis中已经永不了了,mybatis里应该使用parameterType。另外resultMap里面也不能继续使用了改成了type。
同时数据类型的声明和ibatis有了很大的差别,ibatis可以像下面这样写
insert into M_HEALTHSPECIALYTYPE(FCODE,FCHARGE,FTYPECONTENT,FID,FMARK) values (#FCODE:VARCHAR2#,#FCHARGE:VARCHAR2#,#FTYPECONTENT:VARCHAR2#,#FID#,#FMARK:VARCHAR2#)
而在mybatis的话一般是这样弄的:
insert into M_HEALTHSPECIALYTYPE(FCODE,FCHARGE,FTYPECONTENT,FID,FMARK) values (#{FCODE,jdbcType=VARCHAR},#{FCHARGE,jdbcType=VARCHAR},#{FTYPECONTENT,jdbcType=VARCHAR},#{FID},#{FMARK,jdbcType=VARCHAR})
针对映射文件,首先是一系列的属性名称的改变,这些仅仅是名称的改变,用法和含义并没有发生变化:
· 和全局配置文件一样,由于 DTD 约束发生变化,根元素也由原来的
·
·
·
·
· 嵌套参数由 #value# 改为了 #{value}。
·
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 对象,执行数据访问操作等四个步骤。
4.iBatis/MyBatis 对存储过程的支持.
iBatis 中调用存储过程的方式(通过使用
{ ? = call pkgExample.getValues(p_id => ?) }
在 MyBatis 中,
如上所示,通过 statementType 属性将该语句标识为存储过程而非普通 SQL 语句。
总结:
通过前面的示例可以看出,MyBatis 在编码中的最大的改变就是将一个最常用的 API 由 SqlMapClient 改为SqlSessionFactory。另外,类型处理器接口也由原来的 TypeHandlerCallback 改为了 TypeHandler。最后 DataSourceFactory 也进行了调整,移动到 org.apache.ibatis.datasource 包下,其中的方法也作了微调。总之,代码层面公开的部分改动较少,不会给开发者造成较大的移植成本。