Mybatis-Plus的應用場景及注入SQL原理分析

1、背景

1.1 傳統Mybatis的弊端

1.1.1 場景描述

假設有兩張表：一張商品表、一張訂單表，具體表的字段以下：

現有以下需求：

• 分別根據id查詢商品表和訂單表全部信息
• 根據支付狀態和通知狀態查詢訂單表信息
• 對訂單表增長一個訂單狀態，根據訂單狀態查詢訂單信息

1.1.2 需求

需求a:根據id查詢商品表：

​@Select(" SELECT p.id ,p.name ,p.picture ,p.type ,p.price, p.type, p.time
          FROM product p  where id = #{id} ")
List<Product> getProductsBYId(@Param("id") Integer id);

根據id查詢訂單表全部信息：

@Select(" SELECT o.id ,o.pay_no ,o.user_id ,o.product_id ,o.pay_price, o.num, o.pay_time, o.order_type, o.notif_type
          FROM order o  where id = #{id} ")
List<Order> getOrderBYId(@Param("id") Integer id);

需求b：根據支付狀態和通知狀態查詢訂單表信息

​@Select(" SELECT o.id ,o.pay_no ,o.user_id ,o.product_id ,o.pay_price, o.num, o.pay_time, o.order_type, o.notif_type
          FROM order o  where order_type= #{orderType} ")
List<Order> getOrderBYId(@Param("orderType") Integer orderType);
 
@Select(" SELECT o.id ,o.pay_no ,o.user_id ,o.product_id ,o.pay_price, o.num, o.pay_time, o.order_type, o.notif_type
          FROM order o  where notify_type= #{notifyType} ")
List<Order> getOrderBYId(@Param("notifyType") Integer notifyType);

需求c：對訂單表增長一個訂單狀態status，根據訂單狀態查詢訂單信息。

傳統mybaits須要三步：首先須要在訂單表裏加個字段，而後在訂單的實體類添加這個屬性，而且將全部dao層設計該狀態的的查詢sql都修改一遍，加上這個字段。

1.1.3 上述方式有什麼問題呢？

需求a：對於不一樣的實體類，即便查詢的目的一致，仍然須要重複構造相似的sql語句，僅僅是表字段和表信息不一樣。

需求b：對於類似的查詢條件，針對某個單一場景必須構造不一樣的sql，形成sql語句的大量冗餘。

需求c：將dao層全部涉及到新增字段的sql都須要修改一遍，這個過程比較繁瑣且容易出錯。

使用mybatis-plus就能夠解決上述問題。

1.1.4 Myatis-plus的解決方案

首先讓ProductMapper和OrderMapper繼承BaseMapper類：

public interface ProductMapper extends BaseMapper<Product> {
}
 
public interface OrderMapper extends BaseMapper<Order> {
  
}

需求a：

分別根據id查詢商品表和訂單表：因爲BaseMapper中提供了selectById的方法，能夠直接根據具體業務場景，傳入指定的參數例如（id=1）便可。無需書寫具體的sql語句，至於sql自動生成的原理將在下面介紹；

productMapper.selectById(1);
orderMapper.selectById(1);

需求b：

此時利用BaseMapper.selectList(Wapper queryWrapper)方法直接構造查詢條件，例如查詢支付狀態爲2和通知狀態爲1的訂單信息

orderMapper.selectList(new QueryWrapper<Order>().eq("orderType",2));
orderMapper.selectList(new QueryWrapper<Order>().eq("notifyType",1));
orderMapper.selectList(new QueryWrapper<Order>().eq("orderType",2));orderMapper.selectList(new QueryWrapper<Order>().eq("notifyType",1));

此時咱們能夠發現：使用了Mybatis-plus之後，咱們更加聚焦於業務自己，對於上述類似的應用場景，無需構造雷同的SQL，利用包裝器直接傳入查詢條件。

需求c：

前兩步與傳統mybatis一致，因爲MyBatis-plus無需手動建立SQL，所以減小了大量的重複勞動。

1.2 MyBatis-Plus的定位

MyBatis-Plus (opens new window)（簡稱 MP）是一個 MyBatis (opens new window)的加強工具，在 MyBatis 的基礎上只作加強不作改變，爲簡化開發、提升效率而生。

1.3 特性

• 無侵入：只作加強不作改變，引入它不會對現有工程產生影響，如絲般順滑；
• 損耗小：啓動即會自動注入基本 CURD，性能基本無損耗，直接面向對象操做；
• 強大的 CRUD 操做：內置通用 Mapper、通用 Service，僅僅經過少許配置便可實現單表大部分 CRUD 操做，更有強大的條件構造器，知足各種使用需求；
• 支持 Lambda 形式調用：經過 Lambda 表達式，方便的編寫各種查詢條件，無需再擔憂字段寫錯；
• 支持主鍵自動生成：支持多達 4 種主鍵策略（內含分佈式惟一 ID 生成器 - Sequence），可自由配置，完美解決主鍵問題；
• 支持 ActiveRecord 模式：支持 ActiveRecord 形式調用，實體類只需繼承 Model 類便可進行強大的 CRUD 操做；
• 支持自定義全局通用操做：支持全局通用方法注入（ Write once, use anywhere ）；
• 內置代碼生成器：採用代碼或者 Maven 插件可快速生成 Mapper 、 Model 、 Service 、 Controller 層代碼，支持模板引擎，更有超多自定義配置等您來使用；
• 內置分頁插件：基於 MyBatis 物理分頁，開發者無需關心具體操做，配置好插件以後，寫分頁等同於普通 List 查詢；
• 分頁插件支持多種數據庫：支持 MySQL、MariaDB、Oracle、DB二、H二、HSQL、SQLite、Postgre、SQLServer 等多種數據庫；
• 內置性能分析插件：可輸出 Sql 語句以及其執行時間，建議開發測試時啓用該功能，能快速揪出慢查詢；
• 內置全局攔截插件：提供全表 delete 、 update 操做智能分析阻斷，也可自定義攔截規則，預防誤操做。

1.4 原理解析

本文針對MyBatis-plus中的核心功能：SQL自動注入功能，進行流程分析及原理探究。

2、準備工做

先從一個簡單的demo入手，感覺一下MyBatis-plus的便捷性。

2.1 基礎接口BaseMapper

源碼中提供了一個基礎接口，裏面包含了基本的增刪改查方法。

2.2 建立實體類對象

2.3 業務接口UserMapper

業務中根據具體實體對象，繼承該抽象接口。

2.4 測試用例

控制檯顯示：MyBatis-plus最終爲咱們自動生成了SQL語句。根據上述操做分析：UserMapper繼承了BaseMapper，擁有了deleteById的方法，可是MyBatis-plus是基於mybatis的加強版，關鍵在於最終仍然須要提供具體的SQL語句，來進行數據庫操做。

下面就經過debug由上而下分析mybatis-plus是如何生成業務sql以及自動注入的。

3、SQL語句存儲在哪裏？

mappedStatements:描述sql信息

以下圖所示：mybatis爲咱們生成了一個代理對象，裏面包含了一些重要的屬性。

具體以下：

userMapper——>mybatisMapperProxy——>sqlSession——>sqlSessionFactory——>configuration——>mappedStatements——>mappedStatement——>sql語句

至此咱們能夠發現每個SQL語句對應一個mappedStatement，mappedstatements存儲在configuration文件（configuration是mybatis的全局配置文件，包含數據源、mapper、其餘配置信息）中。

4、SQL語句是何時注入的？

4.1 AbstractMethod.addMappedStatement

基於上面的分析，想要知道SQL語句何時拿到的，就是要找到mappedStatement被添加的位置。追蹤到AbstractMethod的抽象方法中。

找到了addMappedStatement()方法

而BaseMapper的全部方法（deleteById、delete、insert、select、update等）都繼承了該抽象方法。

根據mapper方法（deleteById）顯然是調用addDeleteMappedStatement方法。

這裏咱們能夠發現，源碼中根據不一樣的方法繼承AbstractMethod實現了不一樣的實現類，而且實現了injectMappedStatement方法，sqlSource也是在這個地方被添加進配置文件。

4.2 AbstractMethod.inject

繼續研究AbstractMethod抽象類，inject方法實現了自動注入sql的動做。

有上述源碼可知，項目啓動時，首先由默認注入器生成基礎CRUD實現類對象，其次遍歷實現類列表，依次注入各自的模板SQL，最後將其添加至mappedstatement。

5、SQL語句是怎麼生成的？

5.1 SQL模板

上述方法中有兩個關鍵的參數：SqlMethod、SqlSource；

繼續研究源碼發現：sqlMethod本質上是一個枚舉類，存儲了兩個關鍵的元素：

BaseMapper中的方法名；

方法名對應的sql語句模板（即被<scripe>標籤包裹的字符串）。

到這裏咱們基本瞭解了mybaits-plus實現sql自動生成的本質：根據不一樣的方法來提供一些通用的模板，項目啓動後再加載進mappedStatement。

5.2 SqlSource

此時SqlSource經過解析SQL模板、以及傳入的表信息和主鍵信息構建出了SQL語句。

5.3 數據庫表信息是如何獲取的？

分析initTableName()方法：獲取表名信息源碼中傳入了實體類信息clazz，其實就是經過實體上的@TableName註解拿到了表名；

咱們在定義實體類的同時，指定了該實體類對應的表名。

分析initTableFields()方法：

獲取主鍵及其餘字段信息

至此tableInfo的信息已經注入完成了。

在研究完解析mapper的核心過程以後，咱們再簡單看下mapper文件被添加到configuration（mybatis核心配置文件）的過程。

6、mapper文件被添加的過程

ISqlInjector：Sql注入器

MybatisMapperAnnotationBuilder:mapper解析器

MybatisMapperAnnotationBuilder中的parse方法獲取了sqlInjector（Sql注入器）來進行SQL注入。

Mybatis添加mapper的固有流程：MybatisMapperRegistry

調用MapperAnnotionBuilder解析器進行解析

MybatisConfiguration.addMapper

MybatisXMLConfigBuilder.mapperElemnt

MybayisXMLConfigBuilder.parseConfiguration

添加mapper文件的過程分析到這裏就完成了。

7、總結

7.1 流程梳理

下面總結梳理了一下mybatis-plus解析mapper文件自動注入sql的主要流程。

7.2 Mybatis-plus的ORM的核心思想

1）實體類和數據庫表經過自定義註解來完成一一映射。

2）對象屬性和字段一樣使用註解來一一對應（命名注意要相同）。

3）爲了提升複用性使得具體的mapper繼承通用的增刪改查接口。

4）利用模板方法和對象屬性值動態拼接SQL。

8、參考文檔

MyBatis-plus官方文檔：https://mp.baomidou.com/

做者：vivo互聯網服務器團隊-Li Lei