【MyBatis系列6】想要學會MyBatis,看完這一篇就夠了 前言 概要 獲取Mapper接口(getMapper) sql執行流程分析 參數映射 結果集映射 工作流程圖 總結

前言

MyBatis可能很多人都一直在用,但是MyBatis的SQL執行流程可能並不是所有人都清楚了,那麼既然進來了,通讀本文你將收穫如下:

  • 1、Mapper接口和映射文件是如何進行綁定的
  • 2、MyBatis中SQL語句的執行流程
  • 3、自定義MyBatis中的參數設置處理器typeHandler
  • 4、自定義MyBatis中結果集處理器typeHandler

PS:本文基於MyBatis3.5.5版本源碼

概要

在MyBatis中,利用編程式進行數據查詢,主要就是下面幾行代碼:

SqlSession session = sqlSessionFactory.openSession();
UserMapper userMapper = session.getMapper(UserMapper.class);
List<LwUser> userList = userMapper.listUserByUserName("孤狼1號");

第一行是獲取一個SqlSession對象在上一篇文章分析過了,第二行就是獲取UserMapper接口,第三行一行代碼就實現了整個查詢語句的流程,接下來我們就來仔細分析一下第二和第三步。

獲取Mapper接口(getMapper)

第二步是通過SqlSession對象是獲取一個Mapper接口,這個流程還是相對簡單的,下面就是我們調用session.getMapper方法之後的運行時序圖:


  • 1、在調用getMapper之後,會去Configuration對象中獲取Mapper對象,因爲在項目啓動的時候就會把Mapper接口加載並解析存儲到Configuration對象
  • 2、通過Configuration對象中的MapperRegistry對象屬性,繼續調用getMapper方法
    [圖片上傳失敗...(image-29b6ee-1604295628935)]

  • 3、根據type類型,從MapperRegistry對象中的knownMappers獲取到當前類型對應的代理工廠類,然後通過代理工廠類生成對應Mapper的代理類


  • 4、最終獲取到我們接口對應的代理類MapperProxy對象
    [圖片上傳失敗...(image-97a254-1604295628935)]

    而MapperProxy可以看到實現了InvocationHandler,使用的就是JDK動態代理


    至此獲取Mapper流程結束了,那麼就有一個問題了MapperRegistry對象內的HashMap屬性knownMappers中的數據是什麼時候存進去的呢?

Mapper接口和映射文件是何時關聯的

Mapper接口及其映射文件是在加載mybatis-config配置文件的時候存儲進去的,下面就是時序圖:


  • 1、首先我們會手動調用SqlSessionFactoryBuilder方法中的build()方法:


  • 2、然後會構造一個XMLConfigBuilder對象,並調用其parse方法:


  • 3、然後會繼續調用自己的parseConfiguration來解析配置文件,這裏面就會分別去解析全局配置文件的頂級節點,其他的我們先不看,我們直接看最後解析mappers節點


  • 4、繼續調用自己的mapperElement來解析mappers文件(這個方法比較長,爲了方便截圖完整,所以把字體縮小了1號),可以看到,這裏面分了四種方式來解析mappers節點的配置,對應了4種mapper配置方式,而其中紅框內的兩種方式是直接配置的xml映射文件,藍框內的兩種方式是解析直接配置Mapper接口的方式,從這裏也可以說明,不論配置哪種方式,最終MyBatis都會將xml映射文件和Mapper接口進行關聯

  • 5、我們先看第2種和第3中(直接配置xml映射文件的解析方式),會構建一個XMLMapperBuilder對象並調用其parse方法。


    但是這裏有一個問題,如果有多重繼承或者多重依賴時在這裏是可能會無法被完全解析的,比如說三個映射文件互相依賴,那麼if裏面(假設是最壞情況)只能加載1個,失敗2個,然後走到下面if之外的代碼又只能加載1個,還有1個會失敗(如下代碼中,只會處理1次,再次失敗並不會繼續加入incompleteResultMaps):

    當然,這個還是會被解析的,後面執行查詢的時候會再次通過不斷遍歷去全部解析完畢,不過有一點需要注意的是,互相引用這種是會導致解析失敗報錯的,所以在開發過程中我們應該避免循環依賴的產生

  • 6、解析完映射文件之後,調用自身方法bindMapperForNamespace,開始綁定Mapper接口和映射文件:


  • 7、調用Configuration對象的addMapper
    [圖片上傳失敗...(image-f6d6e0-1604295628935)]

  • 8、調用Configuration對象的屬性MapperRegistry內的addMapper方法,這個方法就是正式將Mapper接口添加到knownMappers,所以上面getMapper可以直接獲取:


    到這裏我們就完成了Mapper接口和xml映射文件的綁定

  • 9、注意上面紅框裏面的代碼,又調用了一次parse方法,這個parse方法主要是解析註解,比如下面的語句:

@Select("select * from lw_user")
    List<LwUser> listAllUser();

所以這個方法裏面會去解析@Select等註解,需要注意的是,parse方法裏面會同時再解析一次xml映射文件,因爲上面我們提到了mappers節點有4種配置方式,其中兩種配置的是Mapper接口,而配置Mapper接口會直接先調用addMapper接口,並沒有解析映射文件,所以進入註解解析方法parse之中會需要再嘗試解析一次XML映射文件。

解析完成之後,還會對Mapper接口中的方法進行解析,並將每個方法的全限定類名作爲key存入存入Configuration中的mappedStatements屬性。

需要指出的是,這裏存儲的時候,同一個value會存儲2次,一個全限定名作爲key,另一個就是隻用方法名(sql語句的id)來作爲key

所以最終mappedStatements會是下面的情況:

事實上如果我們通過接口的方式來編程的話,最後來getStatement的時候,都是根據全限定名來取的,所以即使有重名對我們也沒有影響,而之所以要這麼做的原因其實還是爲了兼容早期版本的用法,那就是不通過接口,而是直接通過方法名的方式來進行查詢

session.selectList("com.lonelyWolf.mybatis.mapper.UserMapper.listAllUser");

這裏如果shortName沒有重複的話,是可以直接通過簡寫來查詢的:

session.selectList("listAllUser");

但是通過簡寫來查詢一旦shortName重複了就會拋出以下異常:


這裏的異常其實就是StrickMap的get方法拋出來的:


sql執行流程分析

上面我們講到了,獲取到的Mapper接口實際上被包裝成爲了代理對象,所以我們執行查詢語句肯定是執行的代理對象方法,接下來我們就以Mapper接口的代理對象MapperProxy來分析一下查詢流程。

整個sql執行流程可以分爲兩大步驟:

  • 一、尋找sql
  • 二、執行sql語句

尋找sql

首先還是來看一下尋找sql語句的時序圖:


  • 1、瞭解代理模式的應該都知道,調用被代理對象的方法之後實際上執行的就是代理對象的invoke方法


  • 2、因爲我們這裏並沒有調用Object類中的方法,所以肯定走的else。else中會繼續調用MapperProxy內部類MapperMethodInvoker中的方法cachedInvoker,這裏面會有一個判斷,判斷一下我們是不是default方法,因爲Jdk1.8中接口中可以新增default方法,而default方法是並不是一個抽象方法,所以也需要特殊處理(剛開始會從緩存裏面取,緩存相關知識我們這裏先不講,後面會單獨寫一篇來分析一下緩存))。


  • 3、接下來,是構造一個MapperMethod對象,這個對象封裝了Mapper接口中對應的方法信息以及對應的sql語句信息:


    這裏面就會把要執行的sql語句,請求參數,方法返回值全部解析封裝成MapperMethod對象,然後後面就可以開始準備執行sql語句了

執行sql語句

還是先來看一下執行Sql語句的時序圖:


1、我們繼續上面的流程進入execute方法:


  • 2、這裏面會根據語句類型以及返回值類型來決定如何執行,本人這裏返回的是一個集合,故而我們進入executeForMany方法:


  • 3、這裏面首先會將前面存好的參數進行一次轉換,然後繞了這麼一圈,回到了起點SqlSession對象,繼續調用selectList方法:
  • 3、接下來又講流程委派給了Execute去執行query方法,最終又會去調用queryFromDatabase方法:


  • 4、到這裏之後,終於要進入正題了,一般帶了這種do開頭的方法就是真正做事的,Spring中很多地方也是採用的這種命名方式:


    注意,前面我們的sql語句還是佔位符的方式,並沒有將參數設置進去,所以這裏在return上面一行調用prepareStatement方法創建Statement對象的時候會去設置參數,替換佔位符。參數如何設置我們先跳過,等把流程執行完了我們在單獨分析參數映射和結果集映射。

5、繼續進入PreparedStatementHandler對象的query方法,可以看到,這一步就是調用了jdbc操作對象PreparedStatement中的execute方法,最後一步就是轉換結果集然後返回。
[圖片上傳失敗...(image-cdb73b-1604295628936)]

到這裏,整個SQL語句執行流程分析就結束了,中途有一些參數的存儲以及轉換並沒有深入進去,因爲參數的轉換並不是核心,只要清楚整個數據的流轉流程,我們自己也可以有自己的實現方式,只要存起來最後我們能重新解析讀出來就行。

參數映射

現在我們來看一下上面在執行查詢之前參數是如何進行設置的,我們先進入prepareStatement方法:


我們發現,最終是調用了StatementHandler中的parameterize進行參數設置,接下來這裏爲了節省篇幅,我們不會一步步點進去,直接進入設置參數的方法:


上面的BaseTypeHandler是一個抽象類,setNonNullParameter並沒有實現,都是交給子類去實現,而每一個子類就是對應了數據庫的一種類型。下圖中就是默認的一個子類StringTypeHandler,裏面沒什麼其他邏輯,就是設置參數。


可以看到String裏面調用了jdbc中的setString方法,而如果是int也會調用setInt方法。
看到這些子類如果大家之前閱讀過我前面講的MyBatis參數配置,應該就很明顯可以知道,這些子類就是系統默認提供的一些typeHandler。而這些默認的typeHandler會默認被註冊並和Java對象進行綁定:


正是因爲MyBatis中默認提供了常用數據類型的映射,所以我們寫Sql的時候纔可以省略參數映射關係,可以直接採用下面的方式,系統可以根據我們參數的類型,自動選擇合適的typeHander進行映射:

select user_id,user_name from lw_user where user_name=#{userName}

上面這條語句實際上和下面這條是等價的:

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR}

或者說我們可以直接指定typeHandler:

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=org.apache.ibatis.type.IntegerTypeHandler}

這裏因爲我們配置了typeHandler,所以會優先以配置的typeHandler爲主不會再去讀取默認的映射,如果類型不匹配就會直接報錯了:
[圖片上傳失敗...(image-654edf-1604295628936)]

看到這裏很多人應該就知道了,如果我們自己自定義一個typeHandler,然後就可以配置成我們自己的自定義類。
所以接下來就讓我們看看如何自定義一個typeHandler

自定義typeHandler

自定義typeHandler需要實現BaseTypeHandler接口,BaseTypeHandler有4個方法,包括結果集映射,爲了節省篇幅,代碼沒有寫上來:

package com.lonelyWolf.mybatis.typeHandler;

import org.apache.ibatis.type.BaseTypeHandler;
import org.apache.ibatis.type.JdbcType;

import java.sql.CallableStatement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class MyTypeHandler extends BaseTypeHandler<String> {

    @Override
    public void setNonNullParameter(PreparedStatement preparedStatement, int index, String param, JdbcType jdbcType) throws SQLException {
        System.out.println("自定義typeHandler生效了");
        preparedStatement.setString(index,param);
    }

然後我們改寫一下上面的查詢語句:

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=com.lonelyWolf.mybatis.typeHandler.MyTypeHandler}

然後執行,可以看到,自定義的typeHandler生效了:
[圖片上傳失敗...(image-7b8b5b-1604295628936)]

結果集映射

接下來讓我們看看結果集的映射,回到上面執行sql流程的最後一個方法:

resultSetHandler.handleResultSets(ps)

結果集映射裏面的邏輯相對來說還是挺複雜的,因爲要考慮到非常多的情況,這裏我們就不會去深究每一個細節,直接進入到正式解析結果集的代碼,下面的5個代碼片段就是一個簡單的但是完整的解析流程:


從上面的代碼片段我們也可以看到,實際上解析結果集還是很複雜的,就如我們上一篇介紹的複雜查詢一樣,一個查詢可以不斷嵌套其他查詢,還有延遲加載等等一些複雜的特性
的處理,所以邏輯分支是有很多,但是不管怎麼處理,最後的核心還是上面的一套流程,最終還是會調用typeHandler來獲取查詢到的結果。

是的,你沒猜錯,這個就是上面我們映射參數的typeHandler,因爲typeHandler裏面不只是一個設置參數方法,還有獲取結果集方法(上面設置參數的時候省略了)。

自定義typeHandler結果集

所以說我們還是用上面那個MyTypeHandler 例子來重寫一下取值方法(省略了設置參數方法):

package com.lonelyWolf.mybatis.typeHandler;

import org.apache.ibatis.type.BaseTypeHandler;
import org.apache.ibatis.type.JdbcType;

import java.sql.CallableStatement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class MyTypeHandler extends BaseTypeHandler<String> {

    /**
     * 設置參數
     */
    @Override
    public void setNonNullParameter(PreparedStatement preparedStatement, int index, String param, JdbcType jdbcType) throws SQLException {
        System.out.println("設置參數->自定義typeHandler生效了");
        preparedStatement.setString(index,param);
    }
    /**
     * 根據列名獲取結果
     */
    @Override
    public String getNullableResult(ResultSet resultSet, String columnName) throws SQLException {
        System.out.println("根據columnName獲取結果->自定義typeHandler生效了");
        return resultSet.getString(columnName);
    }

    /**
     * 根據列的下標來獲取結果
     */
    @Override
    public String getNullableResult(ResultSet resultSet, int columnIndex) throws SQLException {
        System.out.println("根據columnIndex獲取結果->自定義typeHandler生效了");
        return resultSet.getString(columnIndex);
    }

    /**
     * 處理存儲過程的結果集
     */
    @Override
    public String getNullableResult(CallableStatement callableStatement, int columnIndex) throws SQLException {
        return callableStatement.getString(columnIndex);
    }
}

改寫Mapper映射文件配置:

 <resultMap id="MyUserResultMap" type="lwUser">
        <result column="user_id" property="userId" jdbcType="VARCHAR" typeHandler="com.lonelyWolf.mybatis.typeHandler.MyTypeHandler" />
        <result column="user_name" property="userName" jdbcType="VARCHAR" />
    </resultMap>

<select id="listUserByUserName" parameterType="String" resultMap="MyUserResultMap">
        select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=com.lonelyWolf.mybatis.typeHandler.MyTypeHandler}
    </select>

執行之後輸出如下:


因爲我們屬性上面只配置了一個屬性,所以只輸出了一次。

工作流程圖

上面介紹了代碼的流轉,可能繞來繞去有點暈,所以我們來畫一個主要的對象之間流程圖來更加清晰的展示一下MyBatis主要工作流程:


從上面的工作流程圖上我們可以看到,SqlSession下面還有4大對象,這4大對象也很重要,後面學習攔截器的時候就是針對這4大對象進行的攔截,關於這4大對象的具體詳情,我們下一篇文章再展開分析。

總結

本文主要分析了MyBatis的SQL執行流程。在分析流程的過程中,我們也舉例論證瞭如何自定義typeHandler來實現自定義的參數映射和結果集映射,不過MyBatis中提供的默認映射其實可以滿足大部分的需求,如果我們對某些屬性需要特殊處理,那麼就可以採用自定義的typeHandle來實現,相信如果本文如果讀懂了,以下幾點大家應該至少會有一個清晰的認識:

  • 1、Mapper接口和映射文件是如何進行綁定的
  • 2、MyBatis中SQL語句的執行流程
  • 3、自定義MyBatis中的參數設置處理器typeHandler
  • 4、自定義MyBatis中結果集處理器typeHandler

當然,其中很多細節並沒有提到,而看源碼我們也並不需要追求每一行代碼都能看懂,就比如我們一個稍微複雜一點的業務系統,即使我們是項目開發者如果某一個模塊不是本人負責的,恐怕也很難搞清楚每一行代碼的含義。所以對於MyBatis及其他框架的源碼中也是一樣,首先應該從大局入手,掌握整體流程和設計思想,然後如果對某些實現細節感興趣,再深入進行了解。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章