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来完成动态分支的判断，因为判断分支过于复杂，而且难以维护。

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