分页处理逻辑应编写在Controller层还是Service层？

先明确各层的核心职责，再对应分页逻辑的不同部分来拆分：

• Service层管数据和核心业务：你提到的从数据库获取totalCount的操作，必须放在Service层——因为Service层的本职就是对接数据层、处理数据相关的业务逻辑，Controller层不该直接触碰数据库查询操作。

• Controller层管请求响应适配：你觉得分页和视图相关的思路是对的，但要拆分逻辑场景：

  • 如果只是计算总页数用于前端展示，那在Controller里计算完全没问题，毕竟这就是把Service返回的totalCount和请求传来的pageSize做简单运算，属于组装响应数据的环节，和视图展示强相关；
  • 要是总页数还要参与业务判断（比如判断是否还有下一页、触发某些业务规则），那得把计算逻辑挪去Service层，封装成业务方法的一部分，避免Controller层掺杂业务逻辑。

举个实际代码的例子更清楚：

Service层代码示例 #

public PageResult getPageData(int pageSize, int offset) {
    // 从数据库查询数据列表和总条数
    List<Data> dataList = dataMapper.selectList(offset, pageSize);
    long totalCount = dataMapper.selectTotalCount();
    // 返回包含原始数据和总条数的结果
    return new PageResult(dataList, totalCount);
}

Controller层代码示例 #

@GetMapping("/data")
public ResponseEntity<PageResponse> getData(@RequestParam int pageSize, @RequestParam int offset) {
    PageResult pageResult = dataService.getPageData(pageSize, offset);
    // 计算总页数，仅用于组装响应给前端
    int totalPages = (int) Math.ceil((double) pageResult.getTotalCount() / pageSize);
    PageResponse response = new PageResponse(pageResult.getDataList(), totalPages, pageSize, offset);
    return ResponseEntity.ok(response);
}

这种分工既符合分层架构的单一职责原则，又能灵活适配不同的业务场景。

内容的提问来源于stack exchange，提问作者changuk