Spring Boot + PageHelper 實現分頁,總結得很全了!
本文來自作者 "臣不貳" 投稿。
CSDN:https://blog.csdn.net/NOT_TWO_CHEN/article/details/109230267
一. 開發準備
1. 開發工具
- IntelliJ IDEA 2020.2.3
2. 開發環境
- Red Hat Open JDK 8u256
- Apache Maven 3.6.3
3. 開發依賴
- SpringBoot
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>
- MyBatis
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>2.1.3</version>
</dependency>
- PageHelper
<dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> <version>1.3.0</version> </dependency>
二. 技術文件
1. 基於SpringBoot
- SpringBoot 官方文件:https://spring.io/projects/spring-boot
- SpringBoot 中文社群:https://springboot.io
2. 基於MyBatis
- MyBatis 官方文件:https://mybatis.org/mybatis-3/zh/index.html
3. 整合PageHelper
- PageHelper 開源倉庫:https://github.com/pagehelper/Mybatis-PageHelper
三. 應用講解
1. 基本使用
在實際專案運用中,PageHelper的使用非常便利快捷,僅通過PageInfo
PageHelper
兩個類,就足以完成分頁功能,然而往往這種最簡單的整合使用方式,卻在很多實際應用場景中,沒有得到充分的開發利用.
接下來是我們最常見的使用方式:
public PageInfo<ResponseEntityDto> page(RequestParamDto param) {
PageHelper.startPage(param.getPageNum(), param.getPageSize());
List<ResoinseEntityDto> list = mapper.selectManySelective(param);
PageInfo<ResponseEntityDto> pageInfo = (PageInfo<ResponseEntityDto>)list;
return pageInfo;
}
在某種程度上而言,上述寫法的確是符合PageHelper的使用規範 :
在集合查詢前使用`PageHelper.startPage(pageNum,pageSize)`,並且*中間不能穿插執行其他SQL*
但是作為Developer的我們,往往只有在追求完美和極致的道路上才能夠尋得突破和機遇;
以下是合理且規範的基本使用:
public PageInfo<ResponseEntityDto> page(RequestParamDto param) {
return PageHelper.startPage(param.getPageNum(), param.getPageSize())
.doSelectPageInfo(() -> list(param))
}
public List<ResponseEntityDto> list(RequestParamDto param) {
return mapper.selectManySelective(param);
}
FAQ
1. 為什麼要重新宣告一個list函式?
答: 往往在很多實際業務應用場景中, 分頁查詢是基於大資料量的表格展示需求來進行的.
然而很多時候,譬如: 內部服務的互相呼叫,OpenAPI
的提供.甚至在某些前後端分離聯調的業務場景中,是同樣需要一個非分頁集合查詢介面來提供服務的.
另外,暫時以上因素拋開不談,我們可以根據上述寫法來定義和規範某些東西譬如: 分頁和集合查詢的分離和解耦(解耦詳情請看進階使用),
分頁請求的請求和響應與實際業務引數的分離(詳情請看進階使用)等等...
2. doSelectPageInfo
是什麼?
答:
doSelectPageInfo
是PageHelper.startPage()
函式返回的預設Page
例項內建的函式,該函式可以用以Lambda
的形式通過額外的Function
來進行查詢而不需要再進行多餘的PageInfo
與List
轉換,而doSelectPageInfo
的引數則是PageHelper
內建的Function(ISelect)
介面用以達到轉換PageInfo
的目的
3. 這種寫法的程式碼量看起來不少反多?
答: 正如同①中所描述的,就程式碼量而言,確實沒有更進一步的簡化,但是再某些業務場景中,在已具有
list
函式介面的情況下,是一種更直觀的優化(優化詳情請看進階使用)
2. 進階使用
先看程式碼,再談解析:
import com.github.pagehelper.PageHelper;
import com.github.pagehelper.PageInfo;
import java.util.List;
/**
* @param <Param> 泛型request
* @param <Result> 泛型response
*/
public interface BaseService<Param, Result> {
/**
* 分頁查詢
*
* @param param 請求引數DTO
* @return 分頁集合
*/
default PageInfo<Result> page(PageParam<Param> param) {
return PageHelper.startPage(param).doSelectPageInfo(() -> list(param.getParam()));
}
/**
* 集合查詢
*
* @param param 查詢引數
* @return 查詢響應
*/
List<Result> list(Param param);
}
可以看到
BaseService
可以作為全域性Service
通用介面的封裝和宣告,而作為通用分頁介面page函式卻在此處利用interface
特有關鍵字default
直接聲明瞭page
函式的方法體body
import com.github.pagehelper.IPage;
import lombok.Data;
import lombok.experimental.Accessors;
@Data // 為省略冗餘程式碼使用lombok 實際應有常規Getter/Setter Construction toString等
@Accessors(chain = true) // 此lombok註解是為了實現 Entity偽Build 譬如: entity.setX(x).setY(y)
public class PageParam<T> implements IPage {
// description = "頁碼", defaultValue = 1
private Integer pageNum = 1;
// description = "頁數", defaultValue = 20
private Integer pageSize = 20;
// description = "排序", example = "id desc"
private String orderBy;
// description = "引數"
private T param;
public PageParam<T> setOrderBy(String orderBy) {
this.orderBy = orderBy; // 此處可優化 優化詳情且看解析
return this;
}
}
在
BaseService
中我們看到了一個新的PageParam
,參考了PageInfo
用以包裝/宣告/分離分頁引數和業務引數,且引數型別為泛型,即支援任何資料型別的業務引數
同時也可以看到PageParam
實現了IPage
介面,並且多了一個orderBy
屬性欄位
import common.base.BaseService;
import dto.req.TemplateReqDto;
import dto.resp.TemplateRespDto;
public interface TemplateService extends BaseService<TemplateReqDto, TemplateeRespDto> {
// 同為interface介面, 業務Service只需要繼承BaseService
// 並根據實際使用場景宣告請求引數和響應結果的Entity實體即可
}
在實際應用中,只需要宣告我們通用的業務查詢請求引數和響應結果即可
import dto.req.TemplateReqDto;
import dto.resp.TemplateRespDto;
import service.TemplateService;
import persistence.mapper.TemplateMapper;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
import java.util.List;
@Slf4j // 基於lombok自動生成logger日誌記錄例項
@Service // SpringBoot中註冊Service Bean的註解
@RequiredArgsConstructor // 基於lombok根據類所有final屬性生成建構函式 即可完成Spring構造注入
public class TemplateServiceImpl implements TemplateService {
private final TemplateMapper mapper;
@Override
public List<TemplateRespDto> list(TemplateReqDto param) {
return mapper.selectManySelective(param) // 可根據實際情況將實體做轉換
}
}
實現類中也只需要重寫
list
方法體,將實際業務場景中需要處理的業務邏輯處理和查詢方法寫入其中,並不需要關心分頁功能
@Slf4j // 同上
@RestController // SpringBoot中註冊Controller Bean的註解
@RequiredArgsConstructor // 同上
public class TemplateController {
public final TemplateService service;
/**
* 分頁查詢
*
* @param pageParam 分頁查詢引數
* @return 分頁查詢響應
*/
@PostMapping(path = "page")
public PageInfo<Result> page(@RequestBody PageParam<Param> pageParam) {
return service.page(pageParam);
}
/**
* 集合查詢
*
* @param listParam 集合查詢引數
* @return 集合查詢響應
*/
@PostMapping(path = "list")
public List<Result> list(@RequestBody Param listParam) {
return service.list(listParam);
}
}
最後編碼
Controller
介面時,也只需要直接呼叫service.page
即可,而請求引數直接用PageParam
包裝,將分頁引數和業務引數分離,在前後端介面聯調中,保持這種分離規範,可以很大程度上的降低溝通和開發成本
FAQ
1. BaseService
作為interface
,page
為什麼可以宣告方法體?
答:
Java8
中新特性之一就是為interface
介面類增加了static/default
方法,即宣告方法後,其子類或實現都將預設具有這些方法,可以直接呼叫
而在此處為Page
方法宣告default
是因為page
函式只關注分頁引數和分頁響應,脫離了業務場景,方法體大相徑庭,所以索性抽象定義出來,免去了其實現的複雜冗餘過程
2. PageParam
的宣告有什麼意義?實現IPage
是為了什麼?
答:
PageParam
是參考PageInfo
編寫的類(不確定往後PageHelper
是否會封裝此類,興許我可以提個Issue
上去,也參與開源框架的開發)
編寫此類的目的就是為了分離分頁和業務資料,讓開發者專注於業務的實現和開發,同時也是對分頁查詢API
的一種規範,無論是請求還是響應都將分頁相關的資料抽離出來,單獨使用
而實現IPage
則是因為IPage
作為PageHelper
內建的interface
,在不瞭解它更多意義上的作用前,可以作為我們分頁引數宣告的一種規範,而IPage
中也只聲明瞭三個方法,分別是pageNum/pageSize/orderBy
的Getter
方法,另外在原始碼分析中,我將會提到實現此介面更深層的意義
3. PageParam
中除了常規的pageNum/pageSize
,為什麼還需要一個orderBy
?
答: 常規的分頁查詢中只需要
pageNum/pageSize
即可完成分頁的目的,但是往往伴隨著分頁查詢的還有篩選排序,而orderBy
則是專注基於SQL的動態傳參排序
4. orderBy
如何使用?會有什麼問題嗎?
答:
orderBy
和pageNum/pageSize
一樣,都是Pagehelper
通過MyBatis
攔截器,在query查詢中注入進去的,所以在前端傳參時,orderBy
引數應為資料庫column desc/asc
這種形式,多欄位排序則可以用逗號(,)拼接,譬如:columnA desc,columnB
,
但是另外一方面又存在兩個問題, 第一就是大多數資料庫表字段設計中,都會使用蛇形case命名,而非常規開發中的駝峰case命名,所以存在一層轉換,而這種轉換可以分配給前端傳參時,也可以分配給後端接參時.
第二就是這樣赤裸裸的將排序欄位暴露在介面中,會存在order by SQL注入的風險,所以在實際使用過程中,我們需要通過某些手段去校驗和排查orderBy
的傳參是否合法,譬如用正則表示式匹配引數值只能含有order by
語法中必要的值,例如欄位名,desc or asc
,不允許包含特殊字元/資料庫關鍵字等
5. pageNum/pageSize
一定需要給預設值嗎?
答: 通過閱讀PageHelper原始碼,我們得知在
Page
查詢引數為null時,它並不會賦予它們預設值,並不進行額外的處理,以至於導致分頁失敗,而給預設值,也是為了謹防前後端除錯介面過程中可能會出現的各種意外
3. 原始碼分析
首先我們看PageHelper.startPage(param)
過程中發生了什麼 :
public static <E> Page<E> startPage(Object params) {
Page<E> page = PageObjectUtil.getPageFromObject(params, true);
Page<E> oldPage = getLocalPage();
if (oldPage != null && oldPage.isOrderByOnly()) {
page.setOrderBy(oldPage.getOrderBy());
}
setLocalPage(page);
return page;
}
這是
PageHelper
繼承(extend)的抽象類PageMethod
中的一個靜態方法
再看程式碼第一行 Page<E> page = PageObjectUtil.getPageFromObject(params, true)
發生了什麼:
public static <T> Page<T> getPageFromObject(Object params, boolean required) {
if (params == null) {
throw new PageException("無法獲取分頁查詢引數!");
} else if (params instanceof IPage) {
IPage pageParams = (IPage)params;
Page page = null;
if (pageParams.getPageNum() != null && pageParams.getPageSize() != null) {
page = new Page(pageParams.getPageNum(), pageParams.getPageSize());
}
if (StringUtil.isNotEmpty(pageParams.getOrderBy())) {
if (page != null) {
page.setOrderBy(pageParams.getOrderBy());
} else {
page = new Page();
page.setOrderBy(pageParams.getOrderBy());
page.setOrderByOnly(true);
}
}
return page;
} else {
... // 此處我只截取了部分程式碼片段, 以上是較為重要的一塊
}
}
可以看到在此方法中,會先判斷
params
是否為null,再而通過instanceof
判斷是否為IPage
的子類或實現類
如果以上兩個if/else
皆不滿足,則PageHelper
則會在我省略貼出的程式碼中通過大量的反射程式碼來獲取pageNum/pageSize
以及orderBy
.
總所皆知,反射在Java中雖然廣泛應用,並且作為語言獨有特性之一,深受廣大開發者的喜愛,但是反射在某種程度上,是需要效能成本的,甚至於現階段很多主流的框架和技術,都在儘量減少反射的運用,以防止框架效能過差,被市場淘汰.
那麼到此為止,我們也終於解釋並知道了為什麼PageParam
要實現IPage
介面了,在此處的程式碼中可以直接通過介面獲取到分頁引數,而不需要通過有損效能的反射獲取PageHelper
需要的引數
繼續看startPage
中的後續程式碼:
public abstract class PageMethod {
protected static final ThreadLocal<Page> LOCAL_PAGE = new ThreadLocal();
protected static boolean DEFAULT_COUNT = true;
public PageMethod() {
}
protected static void setLocalPage(Page page) {
LOCAL_PAGE.set(page);
}
public static <T> Page<T> getLocalPage() {
return (Page)LOCAL_PAGE.get();
}
...
...
}
可以看到
PageHelper
繼承的抽象類PageMethod
中聲明瞭一個Page
的執行緒本地變數,而getLocalPage()
則是為了獲取當前執行緒中的Page
而接下來if (oldPage != null && oldPage.isOrderByOnly())
則是判斷是否存在舊分頁資料
此處的isOrderByOnly
通過getPageFromObject()
函式我們可以知道,當只存在orderBy
引數時,即為true
也就是說,當存在舊分頁資料並且舊分頁資料只有排序引數時,就將舊分頁資料的排序引數列入新分頁資料的排序引數
然後將新的分頁資料page
存入本地執行緒變數中
實際應用場景中,這種情況還是比較少,僅排序而不分頁,所以某種角度上而言,我們僅當了解便好
接下來再看doSelectPageInfo(ISelect)
中發生了什麼:
public <E> PageInfo<E> doSelectPageInfo(ISelect select) {
select.doSelect();
return this.toPageInfo();
}
可以看到,該方法的實現非常簡單明瞭,就是通過註冊宣告
ISelect
介面由開發自定義集合查詢方式並由它內部執行,隨後便返回PageInfo
實體
前面我們有提到,PageHelper
基於MyBatis
攔截器達到分頁的目的,那麼為什麼此處的ISelect.doSelect()
執行,就可以返回PageInfo
實體呢?
實際上這便是攔截器的妙用所在,在select.doSelect()
執行時,會觸發PageHelper
自定義的MyBatis
查詢攔截器,並通過解析SQL和SQL引數,根據資料庫型別,進行分頁,譬如MySQL的limit
,Oracle的Rownum
等,
同時還會在我們定義的查詢SQL之前,PageHelper
會重新生成一條select count(*)的SQL率先執行,已達到它定義Page
內建分頁引數的目的
@Intercepts({@Signature(
type = Executor.class,
method = "query",
args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}
), @Signature(
type = Executor.class,
method = "query",
args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}
)})
public class PageInterceptor implements Interceptor {
private volatile Dialect dialect;
private String countSuffix = "_COUNT";
protected Cache<String, MappedStatement> msCountMap = null;
private String default_dialect_class = "com.github.pagehelper.PageHelper";
public PageInterceptor() {
}
public Object intercept(Invocation invocation) throws Throwable {
...
...
}
}
以上便是PageHelper
內建的自定義MyBatis攔截器,因程式碼量過多,為了保證不違反本博文文不對題的原則,此處不再做多餘講解,如有需要,我可以另行寫一篇部落格單獨解釋並講解MyBatis攔截器的概念和原理,深度解析MyBatis原始碼
拓展
PageHelper
不僅有pageNum/pageSize/orderBy
這幾個引數,更還有pageSizeZero, reasonable
引數等用以更進階的分頁查詢定義,如需更深入的瞭解,我可以另行寫一遍進階PageHelper使用,此文只作為尋常開發使用講解
四. 總結
PageHelper作為GitHub上現在近10K的開源分頁框架,也許程式碼深度和廣度不及主流市場框架和技術,雖然在功能的實現和原理上,造輪子的難度不高,原始碼也很清晰,但是在很大程度上解決了很多基於MyBatis的分頁技術難題,簡化並提示了廣大開發者的效率,這才是開發者們在開發的路上應該向往併為之拼搏的方向和道路.
而我們作為受益者,也不應當僅僅是對其進行基本的使用,開發之餘,我們也應該關注一些框架的拓展,對框架的底層有一定程度上的瞭解,併為之拓展和優化
此處再次放上PageHelper的開源倉庫!
https://mvnrepository.com/artifact/com.github.pagehelper/pagehelper-spring-boot-starter
我是臣不貳, 你,認識我了嗎?
近期熱文推薦:
1.Java 15 正式釋出, 14 個新特性,重新整理你的認知!!
2.終於靠開源專案弄到 IntelliJ IDEA 啟用碼了,真香!
3.我用 Java 8 寫了一段邏輯,同事直呼看不懂,你試試看。。
覺得不錯,別忘了隨手點贊+轉發哦!