MyBatis实战总结

MyBatis的前身是iBatis,它是一个数据持久层框架。封装优化了普通JDBC的过程,如数据库连接的创建、设置SQL语句参数、执行SQL语句、事务、结果映射以及资源释放等。

MyBatis是一个支持普通SQL查询、存储过程和高级映射的优秀持久层框架,使用简单的XML或注解用于配置和原始映射,将POJO和数据库记录进行相互映射。

MyBatis框架分析

我们知道最基础的JDBC操作为以下七个步骤:

(1)加载JDBC驱动

(2)建立并获取数据库连接

(3)创建JDBC Statement对象

(4)设置SQL语句的传入参数

(5)执行SQL语句并获得结果

(6)处理执行结果

(7)释放相关资源

数据库连接的创建、获取和释放代码是可以复用的,而且每一次操作都进行数据库连接的创建和关闭是没有必要的,是浪费资源和影响性能的。使用数据库连接池能够很好的解决这些问题。由于可能会使用不同的连接池,比如采用DBCP的连接池,或者采用容器本身的JNDI数据库连接池,所以可以通过DataSource进行解耦。

使用Spring容器进行管理的MyBatis数据库连接池配置代码如:

基础的JDBC进行操作数据库时,是在Java类中拼装SQL语句进行执行。为了更简单易用以及更高的性能,MyBatis也是采用手写SQL,而不是通过复杂的配置来自动生成SQL(这两种方式的持久化框架俗称“半自动化”和“全自动化”,MyBatis是“半自动化”的翘楚,“全自动化”的代表则是hibernate。这两个持久化框架都非常流行,而且各有自己的长处,可以根据需求适当应用)。SQL放在Java类里会有很多麻烦,第一,可读性太差了,分散在各个Java类里不利于维护和复用;第二,改动Java代码还要重新编译部署。所以需要有统一的文件来存放相关的SQL。

XML文件可以自定义标签,而且可以使用#{参数名}的占位符来标识参数,同时可以引入JSTL中的等这样的标签来设置动态SQL,所以MyBatis中一般定义***Mapper.xml文件来保存SQL。在数据操作中,需要有真正的Java对象来承接外部调用。所以***Mapper.xml文件会有相对应的一个***Mapper.java接口文件,框架暴露这些Mapper对象来和服务层进行对接。

MyBatis通过约定及配置来衔接各个操作。Mapper.java类中的方法名和Mapper.xml中SQL语句的id定义成相同的进行映射;配置#{参数名}来匹配对应的参数。返回结果可能为POJO、Map、List等类型,所以我们需要定义清楚返回结果类型,在SQL语句中需要定义resultMap属性值;执行的结果和返回的POJO对象的数据结构怎么映射,在Mapper.xml文件需要配置映射的POJO对象以及属性。

Mapper.xml、Mapper.java和POJO对象这三个文件是相辅相成的。业务开发中也一般只是需要新增这三个文件内容,数据库连接和事务配置这些构架好后是不太变动的。有工具根据表结构来生成这三个文件,用不用就再说了。

总体来说,MyBatis框架定义Mapper对象来承接外部的调用,框架本身封装了SqlSession、SqlSessionFactory来进行数据库连接;封装了StatementHandler、Executor来执行数据库操作;封装了ResultSetHandler来处理查询结果。我们只需要架构好 SqlSessionFactory的建立方式以及事务管理,根据业务提供Mapper对象。Mybatis结合Spring容器管理是一个不错的选择。

MyBatis使用中几点经验

手动增量配置映射文件

当有工具生成Mapper等配置文件的时候,很多人就不愿意手动写了。其实MyBatis的生成工具不是特别有用,生成的方法几乎不可用,删删改改老半天还不如自己手写快。而且需要新加或修改属性、方法时,也是没法使用生成的文件,因为需要保留好原有的一些属性和方法。手写映射文件时先定义出用到的字段,这样配置文件会简洁清晰,同时结果映射时效率会更高。

Mapper层参数为Map时,由Service层负责重载

Mapper中存在着很多类似方法,可能是分别根据字段来查询记录,或者根据某几个字段来查询。由于不能重载以及为了减少冗余代码,参数一般设置成Map。但参数设为Map会使代码含义模糊,所以需要在service层来实现重载,对外提供的Service是代码自解释的。可以根据具体的参数不同分别调用不同的service方法。

尽量少用if choose等语句

Mybatis的配置SQL时,尽量少用if choose 等标签,能用SQL实现判断的尽量用SQL来判断(CASE WHEN ,DECODE等),可提高查询性能以及便于维护。

我们来看看这样的SQL:

SELECT * FROM USER WHERE

AND CREATE_DATE >= #{startdate} AND CREATE_DATE <= #{enddate}

AND CREATE_DATE >= SYSDATE - 7 AND CREATE_DATE <= SYSDATE

这样的if判断,其实是完全没有必要的,我们可以很简单的采用DECODE来解决默认值问题:

SELECT * FROM USER WHERE

CREATE_DATE >= DECODE(#{startdate},NULL,SYSDATE-7, #{startdate})

AND CREATE_DATE <= DECODE(#{enddate},NULL,SYSDATE,#{enddate})

不过if与choose判断分支是不可能完全去除的,但是推荐使用SQL原生的方式来解决一些动态问题,而不应该完全依赖Mybatis来完成动态分支的判断,因为判断分支过于复杂,而且难以维护。

本文作者:王文(点融黑帮),毕业于帝都仰望星空大学软件工程专业,致力于大型分布式网站的建设。平时对用户增长、数据分析等方面比较关注。原始梦想是成为一个优秀的个人站长,传播分享好东西。

你可能感兴趣的:(MyBatis实战总结)