用了这么多年分页 PageHelper，你确定你真的会用吗？，mysql 应用教程李辉答案

[](

)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<ResoinseEnti

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

tyDto> 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函数只关注_分页参数和分页响应_,脱离了业务场景,方法体大相径庭,所以索性抽象定义出来,免去了其实现的复杂冗余过程