条件分页查询的步骤和常见错误

条件分页查询

我们在编写后端功能接口时，可以说遇到过的最常见的接口就是条件分页查询接口。虽然说这个接口很常见，但是它的变化有很多，面对着不同的数据库表需要封装的条件、service层的实现类中的判断也有着很大的区别。

下面就给大家讲解一下可以举一反三的万能条件分页查询接口的步骤和编写功能代码的时候出现的最常见的错误。

条件分页查询功能接口的步骤

下面讲解的步骤，可以说是非常万能的接口，可以适用于不同的需求和数据库中建表的结构。

1、封装分页配置工具类

@Accessors(chain = true)
@Data
public class BaseRequest<T> implements Serializable {


    @ApiModelProperty(value = "页码", required = true)
    private long current;

    @ApiModelProperty(value = "每页显示多少条", required = true)
    private long size;

    /**
     * 封装分页对象
     * @return
     */
    @ApiModelProperty(hidden = true) // 不在swagger接口文档中显示
    public IPage<T> getPage() {
        return new Page<T>().setCurrent(this.current).setSize(this.size);
    }
}

这个配置类可以说是万能的：

• 需求不需要条件时，只需要分页的时候：
  直接去在service层的实现类中，去调用这个配置类中的getPage方法，从路径中获取到current和size并set到配置类的对象中，这样就可以实现单独的分页操作。
• 需求需要条件分页时：
  只需要封装一个条件实体类，并去继承这个分页的配置类。并在接口中运用@RequsetBody注解，去把前端传回来的条件封装成一个条件对象。之后经过我们的逻辑判断+代码就可以实现对应的功能。

---

2、封装条件实体类

根据需求条件，封装对应的条件字段，并继承第一步的分页配置类，这样就可以实现子类对象调用父类的方法。

/**
 * 封装的条件查询的条件字段
 */
@Data
@Accessors(chain = true)
public class PackageQuery extends BaseRequest<CloudPackage> {
    @ApiModelProperty(value = "用户id")
    private String middleUserid;

    @ApiModelProperty(value = "手机号")
    private String packagePhone;

    @ApiModelProperty(value = "单号")
    private String packageNumber;

    @ApiModelProperty(value = "包裹地址")
    private String packageAddress;

    @ApiModelProperty(value = "创建时间")
    private String gmtCreate;
    
}

---

3、编写controller层的接口

    //C端用户分页条件查询包裹
    @ApiOperation(value = "c端用户查询包裹信息")
    @PostMapping("getPackageInfo")
    public R getPackageInfo(@RequestBody PackageQuery packageQuery){
          IPage<CloudPackage> cloudPackageList  = cloudPackageService.getPackageAllInfo(packageQuery);
        List<CloudPackage> records = cloudPackageList.getRecords();
        System.out.println(records);
        return R.ok().data("cloudPackageList",cloudPackageList);
    }

这个接口的编写，其中我认为最重要的就是：对于@RequestBody注解的运用。

4、编写service层的实现类

由于是两张表联查，所以我注入了另一张表的service。

    @Autowired
    private CloudMiddleService cloudMiddleService;


    //C端用户查询包裹
    @Override
    public IPage<CloudPackage> getPackageAllInfo(PackageQuery packageQuery) {
        //中间表中的userid
        String userid = packageQuery.getMiddleUserid();
        //判断中间中的id是否为空
        if (!StringUtils.isEmpty(userid)) {
            QueryWrapper queryWrapper = new QueryWrapper();
            queryWrapper.eq("middle_userid", userid);
            CloudMiddle one = cloudMiddleService.getOne(queryWrapper);
            String middlePackageid = one.getMiddlePackageid();
                if (!StringUtils.isEmpty(middlePackageid)) {
                    QueryWrapper<CloudPackage> wrapper = new QueryWrapper<>();
                    String packageAddress = packageQuery.getPackageAddress();
                    String packageNumber = packageQuery.getPackageNumber();
                    String packagePhone = packageQuery.getPackagePhone();
                    String gmtCreate = packageQuery.getGmtCreate();
                    if (packageAddress != null) {
                        wrapper.like("package_address", packageAddress);
                    }
                    if (packageNumber != null) {
                        wrapper.like("package_number", packageNumber);
                    }
                    if (packagePhone != null) {
                        wrapper.like("package_phone", packagePhone);
                    }
                    if (gmtCreate != null) {
                        wrapper.like("gmt_create", gmtCreate);
                    }
                    wrapper.eq("id",middlePackageid);
                    wrapper.eq("package_state", 0);
                    IPage<CloudPackage> cloudPackageIPage = baseMapper.selectPage(packageQuery.getPage(), wrapper);
                    return cloudPackageIPage;
                }else{
                    return null;
                }
        }else {
            return null;
        }
    }

这一个就是看的是自己对于功能的理解和自己对于需求敏感程度，还有不可或缺的逻辑性。在编写代码之前，脑袋里就有了一定的框架，这就是逻辑性。

• 对于这一个实现类的编写，可以说没有万能的代码。需求不同、建表结构不同，那么你的逻辑判断就会大不一样。但是总的来说还是没变的。
• 通过条件构造器封装条件。调用分页方法查询信息。
• 分会IPage的对象。

---

常见错误

对于分页条件查询接口，可以说每个项目都是必须的，最基础的。但是最基础的，也有可能出现错误。

1）找不到封装的条件实体类：

错误原因：就是对于注解的运用不正确。@PostMapping注解和@RequestBody注解这两个注解是必须在一起的。如果把@PostMapping注解换成其他的，那么就会报找不到封装的条件实体类。
解决：
正确的运用@RequestBody注解。

2）空指针异常错误：

错误原因：实现类中运用的条件id，和你自己所写的测试id并不相同。
说明：对于多张表中的中间表来说，中间表充当着当间人的作用，表中有很多id。假如前端传过来userid，那么我们如何把数据放到正确的字段当中那？【下面再说】
解决：
就是将你测试的数据和你在实现类中的调用的方法字段相同。比如：你想用userid测试接口，但是你在实现类中调用的是这张表service中的getbyid的方法，这样就肯定会报空指针异常。因为id和userid是两个不同的字段。而又因为你表中的id为非空，所以你用getbyid方法，还不传id数据，那铁定报空指针异常。

3）类型不匹配异常：

错误原因：因为你所写的测试数据和条件实体类中该字段的类型不相同。比如：你写的测试数据是“2002-11-17”，但是条件实体类中该字段的类型是Date。所写的测试数据封装不进去对象中，那么就会报类型不匹配异常。

解决：
将条件实体类中的字段类型改为相匹配的类型。比如：测试数据是“1009-09-08”的数据，那么条件实体类的字段类型就应该是String类型。

4）没有报红的错误：

我们在编写代码的时候，测试可以成功，但是测试出来的数据和结果，不是我们想要的或者与我们的正确结果有偏差，那么这个就是没有报红的错误。
错误原因：逻辑代码可能少了一个条件，或者编写的逻辑有问题。
解决：
反复思考需求功能，并且观察代码的逻辑是否出错，或者遗漏了哪一步逻辑。

比如：我想要查询个人下的包裹信息，但是接口总是查询所有用户的包裹信息。
经过我反复观察逻辑代码和逻辑后，发现没有判断通过用户id拿到的包裹id是否和表中的一样。所以我们应该加一个判断，去通过条件构造器中的eq方法，和表中的数据做一个比对。

---

以上就是我个人的总结，喜欢的可以点赞收藏，要不下次就找不到了！