[[348784]]

 一. 開發(fā)準(zhǔn)備
1. 開發(fā)工具

• IntelliJ IDEA 2020.2.3

2. 開發(fā)環(huán)境

• Red Hat Open JDK 8u256
• Apache Maven 3.6.3

3. 開發(fā)依賴
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> 

二. 技術(shù)文檔
1. 基于SpringBoot
SpringBoot 官方文檔 https://spring.io/projects/spring-boot
SpringBoot 中文社區(qū) https://springboot.io/
2. 基于MyBatis
MyBatis 官方文檔 https://mybatis.org/mybatis-3/zh/index.html
3. 集成PageHelper
PageHelper 開源倉(cāng)庫 https://github.com/pagehelper/Mybatis-PageHelper
三. 應(yīng)用講解
1. 基本使用
在實(shí)際項(xiàng)目運(yùn)用中，PageHelper的使用非常便利快捷，僅通過PageInfo + PageHelper兩個(gè)類，就足以完成分頁功能，然而往往這種最簡(jiǎn)單的集成使用方式，卻在很多實(shí)際應(yīng)用場(chǎng)景中，沒有得到充分的開發(fā)利用．

接下來是我們最常見的使用方式：

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的使用規(guī)范 :

在集合查詢前使用PageHelper.startPage(pageNum,pageSize),并且中間不能穿插執(zhí)行其他SQL。

但是作為Developer的我們,往往只有在追求完美和極致的道路上才能夠?qū)さ猛黄坪蜋C(jī)遇。

以下是合理且規(guī)范的基本使用:

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. 為什么要重新聲明一個(gè)list函數(shù)?
答: 往往在很多實(shí)際業(yè)務(wù)應(yīng)用場(chǎng)景中, 分頁查詢是基于大數(shù)據(jù)量的表格展示需求來進(jìn)行的。

然而很多時(shí)候,譬如: 內(nèi)部服務(wù)的互相調(diào)用,OpenAPI的提供。

甚至在某些前后端分離聯(lián)調(diào)的業(yè)務(wù)場(chǎng)景中,是同樣需要一個(gè)非分頁集合查詢接口來提供服務(wù)的。

另外,暫時(shí)以上因素拋開不談,我們可以根據(jù)上述寫法來定義和規(guī)范某些東西。

譬如: 分頁和集合查詢的分離和解耦(解耦詳情請(qǐng)看進(jìn)階使用),

分頁請(qǐng)求的請(qǐng)求和響應(yīng)與實(shí)際業(yè)務(wù)參數(shù)的分離(詳情請(qǐng)看進(jìn)階使用)等等…

2. doSelectPageInfo是什么?
答: doSelectPageInfo是PageHelper.startPage()函數(shù)返回的默認(rèn)Page實(shí)例內(nèi)置的函數(shù),該函數(shù)可以用以Lambda的形式通過額外的Function來進(jìn)行查詢而不需要再進(jìn)行多余的PageInfo與List轉(zhuǎn)換,而doSelectPageInfo的參數(shù)則是PageHelper內(nèi)置的Function(ISelect)接口用以達(dá)到轉(zhuǎn)換PageInfo的目的。

3. 這種寫法的代碼量看起來不少反多?
答: 正如同①中所描述的,就代碼量而言,確實(shí)沒有更進(jìn)一步的簡(jiǎn)化,但是再某些業(yè)務(wù)場(chǎng)景中,在已具有l(wèi)ist函數(shù)接口的情況下,是一種更直觀的優(yōu)化(優(yōu)化詳情請(qǐng)看進(jìn)階使用)。

2. 進(jìn)階使用
先看代碼,再談解析:

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 請(qǐng)求參數(shù)DTO 
     * @return 分頁集合 
     */ 
    default PageInfo<Result> page(PageParam<Param> param) { 
        return PageHelper.startPage(param).doSelectPageInfo(() -> list(param.getParam())); 
    } 
 
    /** 
     * 集合查詢 
     * 
     * @param param 查詢參數(shù) 
     * @return 查詢響應(yīng) 
     */ 
    List<Result> 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 實(shí)際應(yīng)有常規(guī)Getter/Setter Construction toString等 
@Accessors(chain = true) // 此lombok注解是為了實(shí)現(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<T> setOrderBy(String orderBy) { 
        this.orderBy = orderBy; // 此處可優(yōu)化 優(yōu)化詳情且看解析 
        return this; 
    } 
} 

在BaseService中我們看到了一個(gè)新的PageParam,參考了PageInfo用以包裝/聲明/分離分頁參數(shù)和業(yè)務(wù)參數(shù),且參數(shù)類型為泛型,即支持任何數(shù)據(jù)類型的業(yè)務(wù)參數(shù)。

同時(shí)也可以看到PageParam實(shí)現(xiàn)了IPage接口,并且多了一個(gè)orderBy屬性字段。

import common.base.BaseService; 
import dto.req.TemplateReqDto; 
import dto.resp.TemplateRespDto; 
 
public interface TemplateService extends BaseService<TemplateReqDto, TemplateeRespDto> { 
    // 同為interface接口, 業(yè)務(wù)Service只需要繼承BaseService 
    // 并根據(jù)實(shí)際使用場(chǎng)景聲明請(qǐng)求參數(shù)和響應(yīng)結(jié)果的Entity實(shí)體即可 
} 

在實(shí)際應(yīng)用中,只需要聲明我們通用的業(yè)務(wù)查詢請(qǐng)求參數(shù)和響應(yīng)結(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自動(dòng)生成logger日志記錄實(shí)例 
@Service // SpringBoot中注冊(cè)Service Bean的注解 
@RequiredArgsConstructor // 基于lombok根據(jù)類所有final屬性生成構(gòu)造函數(shù) 即可完成Spring構(gòu)造注入 
public class TemplateServiceImpl implements TemplateService { 
 
    private final TemplateMapper mapper; 
 
    @Override 
    public List<TemplateRespDto> list(TemplateReqDto param) { 
        return mapper.selectManySelective(param) // 可根據(jù)實(shí)際情況將實(shí)體做轉(zhuǎn)換 
    } 
} 

實(shí)現(xiàn)類中也只需要重寫list方法體,將實(shí)際業(yè)務(wù)場(chǎng)景中需要處理的業(yè)務(wù)邏輯處理和查詢方法寫入其中,并不需要關(guān)心分頁功能。

@Slf4j // 同上 
@RestController // SpringBoot中注冊(cè)Controller Bean的注解 
@RequiredArgsConstructor // 同上 
public class TemplateController { 
 
    public final TemplateService service; 
 
    /** 
     * 分頁查詢 
     * 
     * @param pageParam 分頁查詢參數(shù) 
     * @return 分頁查詢響應(yīng) 
     */ 
    @PostMapping(path = "page") 
    public PageInfo<Result> page(@RequestBody PageParam<Param> pageParam) { 
        return service.page(pageParam); 
    } 
 
    /** 
     * 集合查詢 
     * 
     * @param listParam 集合查詢參數(shù) 
     * @return 集合查詢響應(yīng) 
     */ 
    @PostMapping(path = "list") 
    public List<Result> list(@RequestBody Param listParam) { 
        return service.list(listParam); 
    } 
} 

最后編碼Controller接口時(shí),也只需要直接調(diào)用service.page即可,而請(qǐng)求參數(shù)直接用PageParam包裝,將分頁參數(shù)和業(yè)務(wù)參數(shù)分離,在前后端接口聯(lián)調(diào)中,保持這種分離規(guī)范,可以很大程度上的降低溝通和開發(fā)成本。

FAQ
1. BaseService作為interface,page為什么可以聲明方法體?
答: Java8中新特性之一就是為interface接口類增加了static/default方法,即聲明方法后,其子類或?qū)崿F(xiàn)都將默認(rèn)具有這些方法,可以直接調(diào)用。

而在此處為Page方法聲明default是因?yàn)閜age函數(shù)只關(guān)注分頁參數(shù)和分頁響應(yīng),脫離了業(yè)務(wù)場(chǎng)景,方法體大相徑庭,所以索性抽象定義出來,免去了其實(shí)現(xiàn)的復(fù)雜冗余過程。

2. PageParam的聲明有什么意義?實(shí)現(xiàn)IPage是為了什么?
答: PageParam是參考PageInfo編寫的類(不確定往后PageHelper是否會(huì)封裝此類,興許我可以提個(gè)Issue上去,也參與開源框架的開發(fā))。

編寫此類的目的就是為了分離分頁和業(yè)務(wù)數(shù)據(jù),讓開發(fā)者專注于業(yè)務(wù)的實(shí)現(xiàn)和開發(fā),同時(shí)也是對(duì)分頁查詢API的一種規(guī)范,無論是請(qǐng)求還是響應(yīng)都將分頁相關(guān)的數(shù)據(jù)抽離出來,單獨(dú)使用。

而實(shí)現(xiàn)IPage則是因?yàn)镮Page作為PageHelper內(nèi)置的interface,在不了解它更多意義上的作用前,可以作為我們分頁參數(shù)聲明的一種規(guī)范,而IPage中也只聲明了三個(gè)方法,分別是pageNum/pageSize/orderBy的Getter方法,另外在源碼分析中,我將會(huì)提到實(shí)現(xiàn)此接口更深層的意義。

3. PageParam中除了常規(guī)的pageNum/pageSize,為什么還需要一個(gè)orderBy?
答: 常規(guī)的分頁查詢中只需要pageNum/pageSize即可完成分頁的目的,但是往往伴隨著分頁查詢的還有篩選排序,而orderBy則是專注基于SQL的動(dòng)態(tài)傳參排序。

4. orderBy如何使用?會(huì)有什么問題嗎?
答: orderBy和pageNum/pageSize一樣,都是Pagehelper通過MyBatis攔截器,在query查詢中注入進(jìn)去的,所以在前端傳參時(shí),orderBy參數(shù)應(yīng)為數(shù)據(jù)庫column desc/asc這種形式,多字段排序則可以用逗號(hào)(,)拼接,譬如: columnA desc,columnB,

但是另外一方面又存在兩個(gè)問題, 第一就是大多數(shù)數(shù)據(jù)庫表字段設(shè)計(jì)中,都會(huì)使用蛇形case命名,而非常規(guī)開發(fā)中的駝峰case命名,所以存在一層轉(zhuǎn)換,而這種轉(zhuǎn)換可以分配給前端傳參時(shí),也可以分配給后端接參時(shí)。

第二就是這樣赤裸裸的將排序字段暴露在接口中,會(huì)存在order by SQL注入的風(fēng)險(xiǎn),所以在實(shí)際使用過程中,我們需要通過某些手段去校驗(yàn)和排查orderBy的傳參是否合法,譬如用正則表達(dá)式匹配參數(shù)值只能含有order by語法中必要的值,例如字段名,desc or asc,不允許包含特殊字符/數(shù)據(jù)庫關(guān)鍵字等。

5. pageNum/pageSize一定需要給默認(rèn)值嗎?
答: 通過閱讀PageHelper源碼,我們得知在Page查詢參數(shù)為null時(shí),它并不會(huì)賦予它們默認(rèn)值,并不進(jìn)行額外的處理,以至于導(dǎo)致分頁失敗,而給默認(rèn)值,也是為了謹(jǐn)防前后端調(diào)試接口過程中可能會(huì)出現(xiàn)的各種意外。

3. 源碼分析
首先我們看PageHelper.startPage(param)過程中發(fā)生了什么 :

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中的一個(gè)靜態(tài)方法。

再看代碼第一行 Page<E> page = PageObjectUtil.getPageFromObject(params, true)發(fā)生了什么:

public static <T> Page<T> 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 { 
        ... // 此處我只截取了部分代碼片段, 以上是較為重要的一塊 
 } 
} 

可以看到在此方法中,會(huì)先判斷params是否為null,再而通過instanceof判斷是否為IPage的子類或?qū)崿F(xiàn)類。

如果以上兩個(gè)if/else 皆不滿足,則PageHelper則會(huì)在我省略貼出的代碼中通過大量的反射代碼來獲取pageNum/pageSize以及orderBy。

總所皆知,反射在Java中雖然廣泛應(yīng)用,并且作為語言獨(dú)有特性之一,深受廣大開發(fā)者的喜愛,但是反射在某種程度上,是需要性能成本的,甚至于現(xiàn)階段很多主流的框架和技術(shù),都在盡量減少反射的運(yùn)用,以防止框架性能過差,被市場(chǎng)淘汰。

那么到此為止,我們也終于解釋并知道了為什么PageParam要實(shí)現(xiàn)IPage接口了,在此處的代碼中可以直接通過接口獲取到分頁參數(shù),而不需要通過有損性能的反射獲取PageHelper需要的參數(shù)。

繼續(xù)看startPage中的后續(xù)代碼:

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中聲明了一個(gè)Page的線程本地變量,而getLocalPage()則是為了獲取當(dāng)前線程中的Page。

而接下來if (oldPage != null && oldPage.isOrderByOnly())則是判斷是否存在舊分頁數(shù)據(jù)。

此處的isOrderByOnly通過getPageFromObject()函數(shù)我們可以知道,當(dāng)只存在orderBy參數(shù)時(shí),即為true。

也就是說,當(dāng)存在舊分頁數(shù)據(jù)并且舊分頁數(shù)據(jù)只有排序參數(shù)時(shí),就將舊分頁數(shù)據(jù)的排序參數(shù)列入新分頁數(shù)據(jù)的排序參數(shù)。

然后將新的分頁數(shù)據(jù)page存入本地線程變量中。

實(shí)際應(yīng)用場(chǎng)景中,這種情況還是比較少,僅排序而不分頁,所以某種角度上而言,我們僅當(dāng)了解便好。

接下來再看doSelectPageInfo(ISelect) 中發(fā)生了什么:

public <E> PageInfo<E> doSelectPageInfo(ISelect select) { 
 select.doSelect(); 
 return this.toPageInfo(); 
} 

可以看到,該方法的實(shí)現(xiàn)非常簡(jiǎn)單明了,就是通過注冊(cè)聲明ISelect接口由開發(fā)自定義集合查詢方式并由它內(nèi)部執(zhí)行,隨后便返回PageInfo實(shí)體。

前面我們有提到,PageHelper基于MyBatis攔截器達(dá)到分頁的目的,那么為什么此處的ISelect.doSelect()執(zhí)行,就可以返回PageInfo實(shí)體呢?

實(shí)際上這便是攔截器的妙用所在,在select.doSelect()執(zhí)行時(shí),會(huì)觸發(fā)PageHelper自定義的MyBatis查詢攔截器,并通過解析SQL和SQL參數(shù),根據(jù)數(shù)據(jù)庫類型,進(jìn)行分頁,譬如MySQL的limit,Oracle的Rownum等。

同時(shí)還會(huì)在我們定義的查詢SQL之前,PageHelper會(huì)重新生成一條select count(*)的SQL率先執(zhí)行,已達(dá)到它定義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<String, MappedStatement> msCountMap = null; 
    private String default_dialect_class = "com.github.pagehelper.PageHelper"; 
 
    public PageInterceptor() { 
    } 
 
    public Object intercept(Invocation invocation) throws Throwable { 
    ... 
    ... 
    } 
} 

以上便是PageHelper內(nèi)置的自定義MyBatis攔截器,因代碼量過多,為了保證不違反本博文文不對(duì)題的原則,此處不再做多余講解,如有需要,我可以另行寫一篇博客單獨(dú)解釋并講解MyBatis攔截器的概念和原理,深度解析MyBatis源碼。

拓展
PageHelper不僅有pageNum/pageSize/orderBy這幾個(gè)參數(shù),更還有pageSizeZero, reasonable參數(shù)等用以更進(jìn)階的分頁查詢定義,如需更深入的了解,我可以另行寫一遍進(jìn)階PageHelper使用,此文只作為尋常開發(fā)使用講解。

四. 總結(jié)
PageHelper作為GitHub上現(xiàn)在近10K的開源分頁框架,也許代碼深度和廣度不及主流市場(chǎng)框架和技術(shù),雖然在功能的實(shí)現(xiàn)和原理上,造輪子的難度不高,源碼也很清晰,但是在很大程度上解決了很多基于MyBatis的分頁技術(shù)難題,簡(jiǎn)化并提示了廣大開發(fā)者的效率,這才是開發(fā)者們?cè)陂_發(fā)的路上應(yīng)該向往并為之拼搏的方向和道路。

而我們作為受益者,也不應(yīng)當(dāng)僅僅是對(duì)其進(jìn)行基本的使用,開發(fā)之余,我們也應(yīng)該關(guān)注一些框架的拓展,對(duì)框架的底層有一定程度上的了解,并為之拓展和優(yōu)化。

此處再次放上PageHelper的開源倉(cāng)庫!