一、课程内容预览
- 自主完成套餐相关全部接口开发
- 修复根据分类id查询菜品的Bug(额外)
二、笔记
第四天的内容没有视频资源,需要我们使用之前学习到的知识自主地完成套餐相关全部接口的开发,这部分需要各位手操完成,只是在完成这部分时,在最后的测试阶段,我发现了一个业务代码存在的bug,所以想在这里写下我修改bug的历程:
/** * 根据分类id查询菜品 * @param categoryId * @return */@GetMapping("/list")@ApiOperation("根据分类id查询菜品")publicResult<List<Dish>>list(LongcategoryId){List<Dish>list=dishService.list(categoryId);returnResult.success(list);}这个是我们原本设计的接口,这个接口的作用是在添加和修改套餐时,用于快速定位,想要添加入套餐的菜品而使用的
但是最后前后端联调测试的时候我发现前端按照分类查询各个菜品的功能完全正常,不正常的时右上角按照菜品名查询菜品的功能,我仔细研读了前端代码后发现,这个功能会把name属性发送到/admin/dish/list而这个路径正是上面根据分类id查询菜品接口接收数据的请求路径,但是这个接口只接收categoryId一种数据,所以name无法传递过来,自然使得按照菜品名查询的功能失效。这个时候,我试图在同一个请求路径下写两个不同的接口接收数据:
/** * 根据菜品名字查询菜品 * @param name * @return */@GetMapping("/list")@ApiOperation("根据菜品名字查询菜品")publicResult<List<Dish>>getByName(@RequestParamStringname){log.info("根据菜品名字查询菜品:{}",name);List<Dish>dishs=dishService.getByName(name);returnResult.success(dishs);}但是这又导致了另一个严重的bug:两个接口请求路径完全相同,请求方式也一样,Spring 无法区分,启动直接报错。所以我采用了重构这个接口的方法解决问题:
/** * 根据输入信息查询菜品 * @param categoryId * @return */@GetMapping("/list")@ApiOperation("根据输入信息查询菜品")publicResult<List<Dish>>getByCategoryIdOrName(LongcategoryId,Stringname){log.info("根据输入信息查询菜品:{}",categoryId,name);List<Dish>dishs=dishService.list(categoryId,name);returnResult.success(dishs);}使其同时接收两种数据,同时重构了实现类:
/** * 根据分类id查询菜品 * @param categoryId * @return */@OverridepublicList<Dish>list(LongcategoryId,Stringname){Dishdish=Dish.builder().categoryId(categoryId).name(name).status(StatusConstant.ENABLE).build();returndishMapper.list(dish);}使其可以灵活适应这种变化,这样修改后就没有错误了,前端的分类查询菜品和搜索名称查询菜品都可以正常使用。
三、结语
这一天的内容虽然没有视频资源,但却是我前几天学习所有内容的总结,让我能够及时把刚学会的知识转化到项目编写上,算是一次不错的经验积累。