點擊上方?好好學java?，選擇?星標?公眾號

重磅資訊、干貨，第一時間送達

今日推薦：硬剛一周，3W字總結，一年的經驗告訴你如何準備校招！

個人原創100W+訪問量博客：點擊前往，查看更多

作者：臣不貳 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?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?=??1private?Integer?pageNum?=?1;//?description?=?"頁數",?defaultValue?=?20private?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;@Overridepublic?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

推薦文章

• 硬剛一周，3W字總結，一年的經驗告訴你如何準備校招！

• 今年的校招，Java 好拿 offer 嗎？

• 10月了，該聊聊今年秋招了！

• 聊聊在騰訊實習快一個月的感受

原創電子書歷時整整一年總結的?Java 面試 + Java 后端技術學習指南，這是本人這幾年及校招的總結，各種高頻面試題已經全部進行總結，按照章節復習即可，已經拿到了大廠offer。 原創思維導圖掃碼或者微信搜?程序員的技術圈子?回復?面試?領取原創電子書和思維導圖。

總結

以上是生活随笔為你收集整理的SpringBoot项目中，如何更规范的使用PageHelper分页？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。