Spring Boot + PageHelper 實現分頁，總結得很全了！

CSDN：https://blog.csdn.net/NOT_TWO_CHEN/

簡書：https://www.jianshu.com/p/a24a9ff323c9

一. 開發準備

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

Spring Boot 學習理論和實戰推薦：

https://github.com/javastacks/spring-boot-best-practice

三. 應用講解

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函數只關注分頁參數和分頁響應,脫離了業務場景,方法體截然不同,因此索性抽象定義出來,免去了其實現的複雜冗餘過程。關注公衆號Java技術棧可閱讀Java8系列教程。

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攔截器,因代碼量過多,爲了保證不違反本博文文不對題的原則,此處再也不作多餘講解。

拓展

PageHelper不只有pageNum/pageSize/orderBy這幾個參數,更還有pageSizeZero, reasonable參數等用以更進階的分頁查詢定義。

四. 總結

PageHelper做爲GitHub上如今近10K的開源分頁框架,也許代碼深度和廣度不及主流市場框架和技術,雖然在功能的實現和原理上,造輪子的難度不高,源碼也很清晰,可是在很大程度上解決了不少基於MyBatis的分頁技術難題,簡化並提示了廣大開發者的效率,這纔是開發者們在開發的路上應該向往併爲之拼搏的方向和道路。

而咱們做爲受益者,也不該當僅僅是對其進行基本的使用,開發之餘,咱們也應該關注一些框架的拓展,對框架的底層有必定程度上的瞭解,併爲之拓展和優化

此處再次放上PageHelper的開源倉庫!

https://mvnrepository.com/artifact/com.github.pagehelper/pagehelper-spring-boot-starter

---END---推薦閱讀


代碼對比工具，我就用這6個

分享我經常使用的5個免費的在線 SQL 數據庫環境，簡直太方便了！

Spring Boot 三招組合拳，手把手教你打出優雅的後端接口

MySQL 5.7 vs 8.0，你選那個？網友：我繼續原地踏步~



最後，推薦給你們一個有趣有料的公衆號：寫代碼的渣渣鵬，7年老程序員教你寫bug,回覆 面試|資源 送一你整套開發筆記 有驚喜哦