在线问题反馈模块实战(十四):实现在线答疑功能

👨‍🎓作者：bug菌 ✏️博客：CSDN​、掘金等 💌公众号：​​猿圈奇妙屋​​ 🚫特别声明：原创不易，转载请附上原文出处链接和本文声明，谢谢配合。 🙏版权声明：文章里可能部分文字或者图片来源于互联网或者百度百科，如有侵权请联系bug菌处理。

一、概述🔥

       接下来的这几期，bug菌想跟大家分享一下自己昨天刚接到一个临时的需求，热乎着呢，想分享一下自己是如何面对临时需求并制定整个开发周期，其中包括从梳理业务到创建业务表再到实现业务逻辑形成闭环再到与前端对接，其中会穿插一些业务拓展及功能性拓展，这一条龙流程在线与大家一起见证，分享给刚入门的小伙伴，希望对你们有所帮助。

环境说明：idea2019.3 + springboot2.3.1.REALSE + mybati-plus3.2.0 + mysql5.6 + jdk1.8

二、正文🔥

         说到这里，该模块就快要接近尾声了，刚看了下接口文档，应该就还剩下两三个接口了，都是些基础的crud， 肯定不会超过三期 ，这个模块就要完结啦。 

        不知不觉啊，带着你们已经写了14期了，从框架搭建到工具类封装再到现在的接口请求，一路走来，其实认真看我写该模块的小伙伴就能知道，我每一期都是用心在写，用心在教，目的就是为了能带着那些刚入门或者刚进公司的小伙伴们，对于项目新增需求，应该从哪些地方入手，怎么 按部就班，其实就是想给你们带个头，因为当时的我也是从我的老大一手带出来的，这些也是有很大一部分的分析技巧在里边 ，再加上自己的运用实际分析，得以如此。

        所以啊，你们也不要迷茫，看bug菌写的 这些，一篇一篇看过来，对于没有遇到该临时需求的小伙伴 ，也可以根据我的业务场景，自己尝试去写写，顺便 写点 总结，一可以增加自己对业务场景的理解。对不对。

        接下来我要讲的内容就是，对于用户反馈的问题进行在线答疑，对于这一块业务也算正式的形成闭环。既然有人提问，那就应该要有人进行解答处理，对吧。     

        咱们就废话不多说，直接开始今天的内容。

三、如何代码实现分页查询功能🔥

        既然是对于问题进行解答处理，那第一步就是确定请求方式，说到这里，那你肯定要确定入参，有哪些必须参数，根据我对该业务的理解，入参有三，参1：该反馈问题的主键id。参2：答疑详情；参3：答疑人域账号id。为什么要这三参数呢？因为业务给我说只需要收录对问题的一个反馈，那肯定要记录是谁答疑的吧，至于主键id，那是为了针对那条记录进行答疑的。这样讲，你们都能理解了吧？

        既然确定了编辑参数，那我们就直接创建个参数pojo吧。毕竟要规范行事啊。

1️⃣定义分页pojo

        如下是接口请求入参pojo，仅供参考。

@Data
@ApiModel(value = "问题反馈答疑", description = "问题反馈答疑")
public class SolveUserQuestionModel {

    @ApiModelProperty(value = "问题反馈id")
    private String questionId;

    @ApiModelProperty(value = "解决方案详情")
    private String solveContent;

    @ApiModelProperty(value = "解决人域账号id")
    private

2️⃣定义Controller请求

        请求参数pojo也定义好了，接着就是定义请求体了，那自然使用【POST】请求方式来接收Object参数体了，也就是用@RequestBody注解解析参数。然后定义请求路径，还是老话，尽量见名知意，不要瞎命名。由于这里是对问题进行解决，那就定义成“solve”即可。明白人一眼就能看懂。

具体接口请求定义如下：仅供参考。

@PostMapping("/solve")
    @ApiOperation(value = "问题反馈解决方案", notes = "问题反馈解决方案")
    public ResultResponse<Boolean> solveQuestion(@RequestBody {
        return

3️⃣定义接口方法solveQuestion()

        这里就直接定义就好，毕竟具体业务逻辑是写在接口实现类里。

具体接口定义如下：仅供参考。

/**
     * 问题反馈解决方案
     */
    ResultResponse<Boolean> solveQuestion(SolveUserQuestionModel model);

4️⃣实现solveQuestion()方法

        这里我就要来分析一波了，首先对于数据库有个字段，status，业务要求在页面展示时能展示问题是否解决，我这里是将该数据状态与业务状态共用同一个字段，那自然有固定status值。具体如下：status状态值(0:正常，1：删除；2：已解决；3：不予解决；4：解决中；5：问题关闭)。对于该些状态，有些虽然用不上，但是也要预先定义好，说不定后续需求又需要增加，也就直接赋值即可。        

        所以对该如何实现问题答疑，还有一点需要注意的，就是先查询到该条数据是否存在，若空，直接反馈数据不存在即可，这样就避免了update报错场景。

具体业务代码实现如下：

@Override
    public ResultResponse<Boolean> solveQuestion(SolveUserQuestionModel model) {

        UserQuestionsEntity entity = this.getById(model.getQuestionId());
        if (Objects.isNull(entity)) {
            return new ResultResponse<>(ErrorCodeEnum.DATA_NOT_EXIST);
        }
        entity.setSolver(model.getSolver());
        entity.setSolveContent(model.getSolveContent());
        entity.setStatus(2);//2是已解决。

        return new ResultResponse<>(this.updateById(entity));
    }

想必 对于你们而言，那都是轻轻松松的事儿，毕竟也不是啥复杂的业务逻辑。所以不管简单与否，都要将 场景想多，该处理的处理。 

5️⃣接口测试

        接下来，就是接口测试了，我们从数据库找条未答疑的数据进行答疑测试一下。对于接口测试，我还是老样子，直接就postman或者swagger文档直接接口测试了，但是正规流程是需要写test-case走单元测试的，但是我这不要求这些，那就不用管，毕竟我对自己写的且敢公开教学，说明我就有百分百的把握就算不经过单元测试也是没问题的。

        如下我就直接通过swagger测试给大家看一眼哈。

我们先对该条数据看下，它是未答疑的。

在线问题反馈模块实战(十四):实现在线答疑功能_数据库

你们直接到swagger界面，输入对应的参数，请求一下；

在线问题反馈模块实战(十四):实现在线答疑功能_数据_02

对于数据库中该条问题id不存在，我们这里是直接返回自定义msg。

我们给个数据库存在的问题id，我们再次请求一下：

在线问题反馈模块实战(十四):实现在线答疑功能_数据库_03

看结果是执行成功了，我们再执行一下上述的sql语句，查询核对一下，是否有将这些内容写入库。

在线问题反馈模块实战(十四):实现在线答疑功能_数据_04

明显看到是我们参数所传的内容吧，说明该接口逻辑没有问题，供正常使用。

6️⃣总结

        对于越简单的逻辑接口而言，我们都要百分百用心写。