Spring Boot + PageHelper 實現(xiàn)分頁，總結(jié)得很全了！
CSDN：https://blog.csdn.net/NOT_TWO_CHEN/
簡書：https://www.jianshu.com/p/a24a9ff323c9
一. 開發(fā)準備
1. 開發(fā)工具
2. 開發(fā)環(huán)境
Red Hat Open JDK 8u256 Apache Maven 3.6.3
3. 開發(fā)依賴
<dependency>
?<groupId>org.springframework.bootgroupId>
?<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
?<groupId>org.mybatis.spring.bootgroupId>
?<artifactId>mybatis-spring-boot-starterartifactId>
?<version>2.1.3version>
dependency>
PageHelper
<dependency>
?<groupId>com.github.pagehelpergroupId>
?<artifactId>pagehelper-spring-boot-starterartifactId>
?<version>1.3.0version>
dependency>
二. 技術(shù)文檔
1. 基于SpringBoot
2. 基于MyBatis
3. 集成PageHelper
PageHelper 開源倉庫：https://github.com/pagehelper/Mybatis-PageHelper
三. 應用講解
1. 基本使用
在實際項目運用中，PageHelper的使用非常便利快捷，僅通過PageInfo + PageHelper兩個類，就足以完成分頁功能，然而往往這種最簡單的集成使用方式，卻在很多實際應用場景中，沒有得到充分的開發(fā)利用．
接下來是我們最常見的使用方式：
public?PageInfo?page(RequestParamDto?param)? {
?PageHelper.startPage(param.getPageNum(),?param.getPageSize());
?List?list?=?mapper.selectManySelective(param);
?PageInfo?pageInfo?=?(PageInfo)list;
?return?pageInfo;
}?
在某種程度上而言,上述寫法的確是符合PageHelper的使用規(guī)范 :
?在集合查詢前使用`PageHelper.startPage(pageNum,pageSize)`,并且*中間不能穿插執(zhí)行其他SQL*
但是作為Developer的我們,往往只有在追求完美和極致的道路上才能夠?qū)さ猛黄坪蜋C遇; 以下是合理且規(guī)范的基本使用:
public?PageInfo?page(RequestParamDto?param)? {
?return?PageHelper.startPage(param.getPageNum(),?param.getPageSize())
?????.doSelectPageInfo(()?->?list(param))
}?
public?List?list(RequestParamDto?param)? {
?return?mapper.selectManySelective(param);
}
FAQ
1. 為什么要重新聲明一個list函數(shù)?
答: 往往在很多實際業(yè)務應用場景中, 分頁查詢是基于大數(shù)據(jù)量的表格展示需求來進行的. 然而很多時候,譬如: 內(nèi)部服務的互相調(diào)用,
OpenAPI的提供.甚至在某些前后端分離聯(lián)調(diào)的業(yè)務場景中,是同樣需要一個非分頁集合查詢接口來提供服務的. 另外,暫時以上因素拋開不談,我們可以根據(jù)上述寫法來定義和規(guī)范某些東西
譬如: 分頁和集合查詢的分離和解耦(解耦詳情請看進階使用), 分頁請求的請求和響應與實際業(yè)務參數(shù)的分離(詳情請看進階使用)等等...
2. doSelectPageInfo是什么?
答:
doSelectPageInfo是PageHelper.startPage()函數(shù)返回的默認Page實例內(nèi)置的函數(shù),該函數(shù)可以用以Lambda的形式通過額外的Function來進行查詢而不需要再進行多余的PageInfo與List轉(zhuǎn)換,而doSelectPageInfo的參數(shù)則是PageHelper內(nèi)置的Function(ISelect)接口用以達到轉(zhuǎn)換PageInfo的目的
3. 這種寫法的代碼量看起來不少反多?
答: 正如同①中所描述的,就代碼量而言,確實沒有更進一步的簡化,但是再某些業(yè)務場景中,在已具有
list函數(shù)接口的情況下,是一種更直觀的優(yōu)化(優(yōu)化詳情請看進階使用)
2. 進階使用
先看代碼,再談解析:
import?com.github.pagehelper.PageHelper;
import?com.github.pagehelper.PageInfo;
import?java.util.List;
/**
?*?@param??泛型request
?*?@param??泛型response
?*/
public?interface?BaseService<Param,?Result>?{
????/**
?????*?分頁查詢
?????*
?????*?@param?param?請求參數(shù)DTO
?????*?@return?分頁集合
?????*/
????default?PageInfo?page(PageParam?param)? {
????????return?PageHelper.startPage(param).doSelectPageInfo(()?->?list(param.getParam()));
????}
????/**
?????*?集合查詢
?????*
?????*?@param?param?查詢參數(shù)
?????*?@return?查詢響應
?????*/
????List?list(Param?param) ;
}
可以看到
BaseService可以作為全局Service通用接口的封裝和聲明，而作為通用分頁接口page函數(shù)卻在此處利用interface特有關(guān)鍵字default直接聲明了page函數(shù)的方法體body
import?com.github.pagehelper.IPage;
import?lombok.Data;
import?lombok.experimental.Accessors;
@Data?//?為省略冗余代碼使用lombok?實際應有常規(guī)Getter/Setter?Construction?toString等
@Accessors(chain?=?true)?//?此lombok注解是為了實現(xiàn)?Entity偽Build?譬如:?entity.setX(x).setY(y)
public?class?PageParam<T>??implements?IPage?{
????//??description?=?"頁碼",?defaultValue?=??1
????private?Integer?pageNum?=?1;
????//?description?=?"頁數(shù)",?defaultValue?=?20
????private?Integer?pageSize?=?20;
????//?description?=?"排序",?example?=?"id?desc"
????private?String?orderBy;
????//??description?=?"參數(shù)"
????private?T?param;
????public?PageParam?setOrderBy(String?orderBy)? {
????????this.orderBy?=?orderBy;?//?此處可優(yōu)化?優(yōu)化詳情且看解析
????????return?this;
????}
}
在
BaseService中我們看到了一個新的PageParam,參考了PageInfo用以包裝/聲明/分離分頁參數(shù)和業(yè)務參數(shù),且參數(shù)類型為泛型,即支持任何數(shù)據(jù)類型的業(yè)務參數(shù) 同時也可以看到PageParam實現(xiàn)了IPage接口,并且多了一個orderBy屬性字段
import?common.base.BaseService;
import?dto.req.TemplateReqDto;
import?dto.resp.TemplateRespDto;
public?interface?TemplateService?extends?BaseService<TemplateReqDto,?TemplateeRespDto>?{
????//?同為interface接口,?業(yè)務Service只需要繼承BaseService
????//?并根據(jù)實際使用場景聲明請求參數(shù)和響應結(jié)果的Entity實體即可
}
在實際應用中,只需要聲明我們通用的業(yè)務查詢請求參數(shù)和響應結(jié)果即可
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根據(jù)類所有final屬性生成構(gòu)造函數(shù)?即可完成Spring構(gòu)造注入
public?class?TemplateServiceImpl?implements?TemplateService?{
????private?final?TemplateMapper?mapper;
????@Override
????public?List?list(TemplateReqDto?param)? {
????????return?mapper.selectManySelective(param)?//?可根據(jù)實際情況將實體做轉(zhuǎn)換
????}
}
實現(xiàn)類中也只需要重寫
list方法體,將實際業(yè)務場景中需要處理的業(yè)務邏輯處理和查詢方法寫入其中,并不需要關(guān)心分頁功能
@Slf4j?//?同上
@RestController?//?SpringBoot中注冊Controller?Bean的注解
@RequiredArgsConstructor?//?同上
public?class?TemplateController?{
????public?final?TemplateService?service;
????/**
?????*?分頁查詢
?????*
?????*?@param?pageParam?分頁查詢參數(shù)
?????*?@return?分頁查詢響應
?????*/
????@PostMapping(path?=?"page")
????public?PageInfo?page(@RequestBody?PageParam?pageParam)? {
????????return?service.page(pageParam);
????}
????/**
?????*?集合查詢
?????*
?????*?@param?listParam?集合查詢參數(shù)
?????*?@return?集合查詢響應
?????*/
????@PostMapping(path?=?"list")
????public?List?list(@RequestBody?Param?listParam)? {
????????return?service.list(listParam);
????}
}
最后編碼
Controller接口時,也只需要直接調(diào)用service.page即可,而請求參數(shù)直接用PageParam包裝,將分頁參數(shù)和業(yè)務參數(shù)分離,在前后端接口聯(lián)調(diào)中,保持這種==分離規(guī)范==,可以很大程度上的降低溝通和開發(fā)成本。
FAQ
1. BaseService作為interface,page為什么可以聲明方法體?
答:
Java8中新特性之一就是為interface接口類增加了static/default方法,即聲明方法后,其子類或?qū)崿F(xiàn)都將默認具有這些方法,可以直接調(diào)用 而在此處為Page方法聲明default是因為page函數(shù)只關(guān)注分頁參數(shù)和分頁響應,脫離了業(yè)務場景,方法體大相徑庭,所以索性抽象定義出來,免去了其實現(xiàn)的復雜冗余過程。關(guān)注公眾號Java技術(shù)?？砷喿xJava8系列教程。
2. PageParam的聲明有什么意義?實現(xiàn)IPage是為了什么?
答:
PageParam是參考PageInfo編寫的類(不確定往后PageHelper是否會封裝此類,興許我可以提個Issue上去,也參與開源框架的開發(fā)) 編寫此類的目的就是為了分離分頁和業(yè)務數(shù)據(jù),讓開發(fā)者專注于業(yè)務的實現(xiàn)和開發(fā),同時也是對分頁查詢API的一種規(guī)范,無論是請求還是響應都將分頁相關(guān)的數(shù)據(jù)抽離出來,單獨使用 而實現(xiàn)IPage則是因為IPage作為PageHelper內(nèi)置的interface,在不了解它更多意義上的作用前,可以作為我們分頁參數(shù)聲明的一種規(guī)范,而IPage中也只聲明了三個方法,分別是pageNum/pageSize/orderBy的Getter方法,另外在源碼分析中,我將會提到實現(xiàn)此接口更深層的意義
3. PageParam中除了常規(guī)的pageNum/pageSize,為什么還需要一個orderBy?
答: 常規(guī)的分頁查詢中只需要
pageNum/pageSize即可完成分頁的目的,但是往往伴隨著分頁查詢的還有篩選排序,而orderBy則是專注基于SQL的動態(tài)傳參排序
4. orderBy如何使用?會有什么問題嗎?
答:
orderBy和pageNum/pageSize一樣,都是Pagehelper通過MyBatis攔截器,在query查詢中注入進去的,所以在前端傳參時,orderBy參數(shù)應為數(shù)據(jù)庫column desc/asc這種形式,多字段排序則可以用逗號(,)拼接,譬如:columnA desc,columnB, 但是另外一方面又存在兩個問題, 第一就是大多數(shù)數(shù)據(jù)庫表字段設(shè)計中,都會使用==蛇形case==命名,而非常規(guī)開發(fā)中的==駝峰case==命名,所以存在一層轉(zhuǎn)換,而這種轉(zhuǎn)換可以分配給前端傳參時,也可以分配給后端接參時. 第二就是這樣赤裸裸的將排序字段暴露在接口中,會存在order by SQL注入的風險,所以在實際使用過程中,我們需要通過某些手段去校驗和排查orderBy的傳參是否合法,譬如用正則表達式匹配參數(shù)值只能含有order by語法中必要的值,例如字段名,desc or asc,不允許包含特殊字符/數(shù)據(jù)庫關(guān)鍵字等
5. pageNum/pageSize一定需要給默認值嗎?
答: 通過閱讀PageHelper源碼,我們得知在
Page查詢參數(shù)為null時,它并不會賦予它們默認值,并不進行額外的處理,以至于導致分頁失敗,而給默認值,也是為了謹防前后端調(diào)試接口過程中可能會出現(xiàn)的各種意外
3. 源碼分析
首先我們看PageHelper.startPage(param)過程中發(fā)生了什么 :
public?static??Page?startPage(Object?params)? {
?Page?page?=?PageObjectUtil.getPageFromObject(params,?true);
?Page?oldPage?=?getLocalPage();
?if?(oldPage?!=?null?&&?oldPage.isOrderByOnly())?{
??page.setOrderBy(oldPage.getOrderBy());
?}
?setLocalPage(page);
?return?page;
}
這是
PageHelper繼承(extend)的抽象類PageMethod中的一個靜態(tài)方法
再看代碼第一行 Page發(fā)生了什么:
public?static??Page?getPageFromObject(Object?params,?boolean?required)? {
?if?(params?==?null)?{
??throw?new?PageException("無法獲取分頁查詢參數(shù)!");
?}?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的子類或?qū)崿F(xiàn)類 如果以上兩個if/else皆不滿足,則PageHelper則會在我省略貼出的代碼中通過大量的反射代碼來獲取pageNum/pageSize以及orderBy. 總所皆知,反射在Java中雖然廣泛應用,并且作為語言獨有特性之一,深受廣大開發(fā)者的喜愛,但是反射在某種程度上,是需要性能成本的,甚至于現(xiàn)階段很多主流的框架和技術(shù),都在盡量減少反射的運用,以防止框架性能過差,被市場淘汰. 那么到此為止,我們也終于解釋并知道了為什么PageParam要實現(xiàn)IPage接口了,在此處的代碼中可以直接通過接口獲取到分頁參數(shù),而不需要通過有損性能的反射獲取PageHelper需要的參數(shù)
繼續(xù)看startPage中的后續(xù)代碼:
public?abstract?class?PageMethod?{
????protected?static?final?ThreadLocal?LOCAL_PAGE?=?new?ThreadLocal();
????protected?static?boolean?DEFAULT_COUNT?=?true;
????public?PageMethod()?{
????}
????protected?static?void?setLocalPage(Page?page)?{
????????LOCAL_PAGE.set(page);
????}
????public?static??Page?getLocalPage()? {
????????return?(Page)LOCAL_PAGE.get();
????}
?...
?...
}
可以看到
PageHelper繼承的抽象類PageMethod中聲明了一個Page的線程本地變量,而getLocalPage()則是為了獲取當前線程中的Page而接下來if (oldPage != null && oldPage.isOrderByOnly())則是判斷是否存在舊分頁數(shù)據(jù) 此處的isOrderByOnly通過getPageFromObject()函數(shù)我們可以知道,當只存在orderBy參數(shù)時,即為true也就是說,當存在舊分頁數(shù)據(jù)并且舊分頁數(shù)據(jù)只有排序參數(shù)時,就將舊分頁數(shù)據(jù)的排序參數(shù)列入新分頁數(shù)據(jù)的排序參數(shù) 然后將新的分頁數(shù)據(jù)page存入本地線程變量中 實際應用場景中,這種情況還是比較少,僅排序而不分頁,所以某種角度上而言,我們僅當了解便好
接下來再看doSelectPageInfo(ISelect) 中發(fā)生了什么:
public??PageInfo?doSelectPageInfo(ISelect?select)? {
?select.doSelect();
?return?this.toPageInfo();
}
可以看到,該方法的實現(xiàn)非常簡單明了,就是通過注冊聲明
ISelect接口由開發(fā)自定義集合查詢方式并由它內(nèi)部執(zhí)行,隨后便返回PageInfo實體 前面我們有提到,PageHelper基于MyBatis攔截器達到分頁的目的,那么為什么此處的ISelect.doSelect()執(zhí)行,就可以返回PageInfo實體呢? 實際上這便是攔截器的妙用所在,在select.doSelect()執(zhí)行時,會觸發(fā)PageHelper自定義的MyBatis查詢攔截器,并通過解析SQL和SQL參數(shù),根據(jù)數(shù)據(jù)庫類型,進行分頁,譬如MySQL的limit,Oracle的Rownum等, 同時還會在我們定義的查詢SQL之前,PageHelper會重新生成一條select count(*)的SQL率先執(zhí)行,已達到它定義Page內(nèi)置分頁參數(shù)的目的
@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?msCountMap?=?null;
????private?String?default_dialect_class?=?"com.github.pagehelper.PageHelper";
????public?PageInterceptor()?{
????}
????public?Object?intercept(Invocation?invocation)?throws?Throwable?{
????...
????...
????}
}
以上便是PageHelper內(nèi)置的自定義MyBatis攔截器,因代碼量過多,為了保證不違反本博文文不對題的原則,此處不再做多余講解。
拓展
PageHelper不僅有pageNum/pageSize/orderBy這幾個參數(shù),更還有pageSizeZero, reasonable參數(shù)等用以更進階的分頁查詢定義。
四. 總結(jié)
PageHelper作為GitHub上現(xiàn)在近10K的開源分頁框架,也許代碼深度和廣度不及主流市場框架和技術(shù),雖然在功能的實現(xiàn)和原理上,造輪子的難度不高,源碼也很清晰,但是在很大程度上解決了很多基于MyBatis的分頁技術(shù)難題,簡化并提示了廣大開發(fā)者的效率,這才是開發(fā)者們在開發(fā)的路上應該向往并為之拼搏的方向和道路。
而我們作為受益者,也不應當僅僅是對其進行基本的使用,開發(fā)之余,我們也應該關(guān)注一些框架的拓展,對框架的底層有一定程度上的了解,并為之拓展和優(yōu)化
此處再次放上PageHelper的開源倉庫!
https://mvnrepository.com/artifact/com.github.pagehelper/pagehelper-spring-boot-starter
---END--- 推薦閱讀
分享我常用的5個免費的在線 SQL 數(shù)據(jù)庫環(huán)境，簡直太方便了！
Spring Boot 三招組合拳，手把手教你打出優(yōu)雅的后端接口
MySQL 5.7 vs 8.0，你選那個？網(wǎng)友：我繼續(xù)原地踏步~
最后，推薦給大家一個有趣有料的公眾號：寫代碼的渣渣鵬，7年老程序員教你寫bug,回復 面試|資源 送一你整套開發(fā)筆記 有驚喜哦
