前面我已经写了几篇文章介绍mybatis的使用方法, 现准备从原理上分析mybatis, 本篇将会解说JDBC演变到mybatis的过程。
JDBC查询
使用jdbc查询数据库一般有下面七个步骤:
1. 载入数据库驱动
2. 获取数据库连接
3. 创建Statement对象
4. 传入參数
5. 运行sql语句
6. 处理查询结果
7. 释放资源
public class JDBC {
public static List<Map<String, Object>> queryForList() {
Connection connection = null;
ResultSet rs = null;
PreparedStatement pst = null;
List<Map<String, Object>> resultList = new ArrayList<Map<String, Object>>();
try {
// 1.载入JDBC驱动
Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
String url = "jdbc:oracle:thin:@localhost:1521:ORACLEDB";
String user = "root";
String password = "root";
// 2.获取数据库连接
connection = DriverManager.getConnection(url, user, password);
// 3.创建Statement对象（每个Statement为一次数据库运行请求）
pst = connection.prepareStatement("select * from userinfo where user_id = ? ");
// 4.设置传入參数
pst.setString(1, "zhangsan");
// 5.运行SQL语句
rs = pst.executeQuery();
// 6.处理查询结果（将查询结果转换成List<Map>格式）
ResultSetMetaData rsmd = rs.getMetaData();
int num = rsmd.getColumnCount();
while (rs.next()) {
Map<String, Object> map = new HashMap<String, Object>();
for (int i = 0; i < num; i++) {
String columnName = rsmd.getColumnName(i + 1);
map.put(columnName, rs.getString(columnName));
}
resultList.add(map);
}
} catch (Exception e) {
e.printStackTrace();
} finally {
try {
// 7.释放资源
if (rs != null) {
rs.close(); // 关闭结果集
rs = null;
}
if (pst != null) {
pst.close();
pst = null; // 关闭运行对象
}
if (connection != null) {
connection.close(); // 关闭连接
connection = null;
}
} catch (SQLException e) {
e.printStackTrace();
}
}
return resultList;
}
}优化过程
上面我们看到了使用JDBC查询查询有七个步骤，哪些步骤是能够进一步封装的，并降低我们开发的代码量的呢?
第一步优化：连接的获取和释放
问题描写叙述：数据库连接频繁的开启和关闭本身就造成了资源的浪费，影响系统的性能。
解决的方法：数据库连接的获取和关闭我们能够使用数据库连接池来解决资源浪费的问题。通过连接池就能够重复利用已经建立的连接去訪问数据库了。降低连接的开启和关闭的时间。
问题描写叙述：可是如今连接池多种多样，可能存在变化，有可能採用DBCP的连接池，也有可能C3P0数据库连接池。
解决的方法：我们能够通过DataSource进行隔离解耦，我们统一从DataSource里面获取数据库连接，DataSource详细由DBCP实现还是由C3P0实现都能够，所以我们将DataSource的详细实现通过让用户配置来应对变化。
第二步优化：SQL统一存取
问题描写叙述：我们使用JDBC进行操作数据库时，SQL语句基本都散落在各个JAVA类中，这样有三个不足之处：
第一，可读性非常差，不利于维护以及做性能调优。
第二，修改Java代码须要又一次编译、打包部署。
第三，不利于取出SQL在数据库client运行（取出后还得删掉中间的Java代码，编写好的SQL语句写好后还得通过＋号在Java进行拼凑）。
解决的方法：我们能够考虑不把SQL语句写到Java代码中，那么把SQL语句放到哪里呢？首先须要有一个统一存放的地方，我们能够将这些SQL语句统一集中放到配置文件。然后通过SQL语句的key值去获取相应的SQL语句。
第三步优化：传入參数映射和动态SQL
问题描写叙述：非常多情况下，我们都可以通过在SQL语句中设置占位符来达到使用传入參数的目的，这种方式本身就有一定局限性，它是依照一定顺序传入參数的，要与占位符一一匹配。可是，假设我们传入的參数是不确定的（比方列表查询，依据用户填写的查询条件不同，传入查询的參数也是不同的，有时是一个參数、有时可能是三个參数），那么我们就得在后台代码中自己依据请求的传入參数去拼凑相应的SQL语句，这种话还是避免不了在Java代码里面写SQL语句的命运。既然我们已经把SQL语句统一存放在配置文件或者数据库中了，怎么做到可以依据前台传入參数的不同，动态生成相应的SQL语句呢？
解决的方法：第一，我们先解决这个动态问题，依照正常的思维是使用if和else这类的推断，这个时候我们想到了JSTL中的<if test=””></if>这种标签，那么，能不能将这类的标签引入到SQL语句中呢？如果能够，那么我们这里就须要一个专门的SQL解析器来解析这种SQL语句，可是，if推断的变量来自于哪里呢？传入的值本身是可变的，那么我们得为这个值定义一个不变的变量名称，并且这个变量名称必须和相应的值要有相应关系，能够通过这个变量名称找到相应的值，这个时候我们想到了key-value的Map。解析的时候依据变量名的详细值来推断。假如前面能够推断没有问题，那么假如推断的结果是true，那么就须要输出的标签里面的SQL片段，可是怎么解决在标签里面使用变量名称的问题呢？这里我们须要使用一种有别于SQL的语法来嵌入变量（比方使用＃变量名＃）。这样，SQL语句经过解析后就能够动态的生成符合上下文的SQL语句。
还有，怎么区分开占位符变量和非占位变量？有时候我们单单使用占位符是满足不了的，占位符仅仅能为查询条件占位，SQL语句其它地方使用不了。这里我们能够使用#变量名#表示占位符变量，使用$变量名$表示非占位符变量。
第四步优化：结果映射和结果缓存
问题描写叙述：运行SQL语句、获取运行结果、对运行结果进行转换处理、释放相关资源是一整套下来的。假如是运行查询语句，那么运行SQL语句后，返回的是一个ResultSet结果集，这个时候我们就须要将ResultSet对象的数据取出来，不然等到释放资源时就取不到这些结果信息了。我们从前面的优化来看，以及将获取连接、设置传入參数、运行SQL语句、释放资源这些都封装起来了，仅仅剩下结果处理这块还没有进行封装，假设能封装起来，每一个数据库操作都不用自己写那么一大堆Java代码，直接调用一个封装的方法就能够搞定了。
解决的方法：我们分析一下，一般对运行结果的有哪些处理，有可能将结果不做不论什么处理就直接返回，也有可能将结果转换成一个JavaBean对象返回、一个Map返回、一个List返回等等，结果处理可能是多种多样的。从这里看，我们必须告诉SQL处理器两点：第一，须要返回什么类型的对象；第二，须要返回的对象的数据结构怎么跟运行的结果映射，这样才干将详细的值copy到相应的数据结构上。
接下来，我们能够进而考虑对SQL运行结果的缓存来提升性能。缓存数据都是key-value的格式，那么这个key怎么来呢？怎么保证唯一呢？即使同一条SQL语句几次訪问的过程中因为传入參数的不同，得到的运行SQL语句也是不同的。那么缓存起来的时候是多对。可是SQL语句和传入參数两部分合起来能够作为数据缓存的key值。
第五步优化：解决反复SQL语句问题
问题描写叙述：因为我们将全部SQL语句都放到配置文件里，这个时候会遇到一个SQL反复的问题，几个功能的SQL语句事实上都差点儿相同，有些可能是SELECT后面那段不同、有些可能是WHERE语句不同。有时候表结构改了，那么我们就须要改多个地方，不利于维护。
解决的方法：当我们的代码程序出现反复代码时怎么办？将反复的代码抽离出来成为独立的一个类，然后在各个须要使用的地方进行引用。对于SQL反复的问题，我们也能够採用这样的方式，通过将SQL片段模块化，将反复的SQL片段独立成一个SQL块，然后在各个SQL语句引用反复的SQL块，这样须要改动时仅仅须要改动一处就可以。
优化总结
总结一下上面对JDBC的优化和封装：
（1） 使用数据库连接池对连接进行管理
（2） SQL语句统一存放到配置文件
（3） SQL语句变量和传入參数的映射以及动态SQL
（4） 动态SQL语句的处理
（5） 对数据库操作结果的映射和结果缓存
（6） SQL语句的反复问题