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


一、背景

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、DB2、H2、HSQL、SQLite、Postgre、SQLServer 等多種數據庫;

  • 內置性能分析插件:可輸出 Sql 語句以及其執行時間,建議開發測試時啟用該功能,能快速揪出慢查詢;

  • 內置全局攔截插件:提供全表 delete 、 update 操作智能分析阻斷,也可自定義攔截規則,預防誤操作。

1.4 原理解析

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

二、准備工作

先從一個簡單的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以及自動注入的。

三、SQL語句存儲在哪里?

mappedStatements:描述sql信息

如下圖所示:mybatis為我們生成了一個代理對象,里面包含了一些重要的屬性。

具體如下:

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

至此我們可以發現每一個SQL語句對應一個mappedStatement,mappedstatements存儲在configuration文件(configuration是mybatis的全局配置文件,包含數據源、mapper、其他配置信息)中。

四、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。

五、SQL語句是怎么生成的?

5.1 SQL模板

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

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

BaseMapper中的方法名;

方法名對應的sql語句模板(即被 標簽包裹的字符串)。

到這里我們基本了解了mybaits-plus實現sql自動生成的本質:根據不同的方法來提供一些通用的模板,項目啟動后再加載進mappedStatement。

5.2 SqlSource

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

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

分析initTableName()方法:獲取表名信息源碼中傳入了實體類信息clazz,其實就是通過實體上的@TableName注解拿到了表名;

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

分析initTableFields()方法:

獲取主鍵及其他字段信息

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

在研究完解析mapper的核心過程之后,我們再簡單看下mapper文件被添加到configuration(mybatis核心配置文件)的過程。

六、mapper文件被添加的過程

ISqlInjector:Sql注入器

MybatisMapperAnnotationBuilder:mapper解析器

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

Mybatis添加mapper的固有流程:MybatisMapperRegistry

調用MapperAnnotionBuilder解析器進行解析

MybatisConfiguration.addMapper

MybatisXMLConfigBuilder.mapperElemnt

MybayisXMLConfigBuilder.parseConfiguration

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

七、總結

7.1 流程梳理

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

7.2 Mybatis-plus的ORM的核心思想

1)實體類和數據庫表通過自定義注解來完成一一映射。

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

3)為了提高復用性使得具體的mapper繼承通用的增刪改查接口。

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

八、參考文檔

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

作者:vivo互聯網服務器團隊-Li Lei


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM