一、新增套餐
1.1需求分析与设计
分析
套餐名必须唯一
套餐必须属于某个分类
套餐必须包含菜品
名称,分类,价格,图片为必填项
添加菜品窗口需要根据分类来展示菜品
新增的套餐默认为停售状态
接口设计:
根据类型查询分类✅
根据分类id查询菜品
图片上传✅
新增套餐
页面原型

接口文档
根据分类id查询菜品

新增套餐



1.2代码实现
根据分类id查询菜品
controller层

service层

dao层

新增套餐
controller层

service层

mapper层
插入套餐


保存套餐菜品关系

1.3功能测试


二、套餐分页查询
2.1需求分析与设计
接口文档


2.2代码实现
controller层

service层

dao层

2.3功能测试

三、删除套餐
3.1需求分析与设计
业务规则:
可以一次删除一个套餐,也可以一次删除多个套餐
起售中的菜品无法删除
查看接口文档

3.2代码实现
controller层

service层

dao层


3.3功能测试

四、修改套餐
4.1需求分析与设计
接口设计:
根据id查询套餐
根据类型查询分类✅
根据分类id查询菜品✅
图片上传✅
修改套餐
查看接口文档:
根据id查询套餐

修改套餐


4.2代码实现
根据id查询套餐
controller层

service层

dao层
步骤一:根据套餐id获取套餐信息

步骤二:根据套餐id获取菜品信息

修改套餐
controller层

service层

dao层
步骤一:更新套餐表



步骤二:删除关联表

步骤三:重新插入关联表

4.3功能测试

五、起售停售套餐
5.1需求分析与设计
需求分析:
若要将套餐改为起售先判断套餐相关菜品是否已全部起售
再修改套餐为起售
查看接口文档


5.2代码实现
controller层

service层

dao层

5.3功能测试

六、小结
编写SQL语句的时候有些细节没有注意到,比如setmeal表的name(s.name)直接写作了name,以及desc被写成了decs。下次在编写多表查询或较长SQL语句时,可以先使用控制台输出一下,检查一下再进行编写。不过好在已经能熟练看懂控制台报的什么错了,也算是锻炼到了吧。
编写启用禁用代码时想到了判断菜品是否起售就是想不到多表查询,当时考虑到了要根据前端传入的套餐id查菜品,甚至想到了用套餐id去套餐菜品关系表中先查关联的菜品id,再去菜品表里根据菜品id查询菜品状态,确保套餐启用时菜品都在起售状态。但是没有想到直接多表查询就好了
select d.* from dish d left join setmeal_dish sd on d.id = sd.dish_id where sd.setmeal_id = #{setmealId}
