PageHelper在SpringBoot+MyBatis中合理且規範的使用方法

PageHelper

一. 開發準備

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 官方文檔
• SpringBoot 中文社群

2. 基于MyBatis

• MyBatis 官方文檔

3. 內建PageHelper

• 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在SpringBoot+MyBatis中合理且規範的使用方法_不貳極端程式設計-CSDN部落格

原出處：CSDN部落格

侵删