删除菜品
一、需求分析和设计
●通过产品原型来了解我们这一块的需求
→每一个菜品后面都对应一个删除按钮,或者勾选多个菜品进行批量删除(单个删除/批量删除)
●业务规则:
①可以一次删除一个菜品,也可以批量删除菜品
②起售中的菜品不能删除
③被套餐关联的菜品不能删除
④删除菜品后,关联的口味数据也需要删除掉
●接口设计:
(批量删除和单独删除一样,可用同一个接口)
请求路径:/admin/dish,
请求参数(Query):参数名称:ids(菜品的ID,多个菜品ID之间用逗号分隔eg.1,2,3),
请求方式:delete
返回数据:code
●数据库设计(得运行三张表dish菜品表,dish_flavor菜品口味表,setemeal_dish套餐和菜品的中间关系表[菜品是否被某个套餐给关联])

二、代码创建
●@RequestParam加上这个注解,那我们的mvc就会自己动态的解析这个字符串,我把这个ID动态的提取出来。eg.提取到list集合当中,封装到这个集合对象当中。
●controller层

●serviceimpl层的逻辑
//①判断当前菜品是否能够删除,是否存在起售中的菜品
②判断当前菜品是否能够删除,是否被套餐关联
③删除菜品表中的菜品数据
④删除菜品关联的口味数据
●mapper层,需要3个(SetemealDishMapper[里面的内容是根据菜品id来查询套餐id],DishMapper,DishflavorMapper)
●因为这里涉及多个表的操作,所以在Serviceimpl里面的方法上整体加上一个事务注解@Transactional,保证一致性
三、功能测试
刚刚写的代码,还有进一步的优化空间,主要优化:删除菜品表中的菜品数据(这里我们刚开始用的是一个for循环,在每一次for循环遍历的时候,都会遍历两条sql[删除菜品+删除菜品口味],因为如果遍历的次数很多,那么我们发出的sql就会很多,就有可能引发性能问题,弄好之后就剩下两条固定的sql语句)
修改菜品
一、需求分析和设计
来通过产品原型来查看一下
●修改页面和新增页面很类似,区别就是在输入框的地方,得回显
●在修改菜品之前,需要将菜品的信息查询一下,用于回显,这个查询操作对应一个接口。大家这里该菜品分类其实是一个下拉框,这里要求展示出来所有菜品的分类,于是这里也是得去查询的,一个接口。就是查询分类又还有这个菜品图片,有可能重新上传,因而上传图片,这又是一个接口。当我点击保存按钮的时候,要将整张表单提交,更新到数据库里就是最终就,这又是一个接口,一共四个接口。
●接口设计:
①根据ID查询菜品(肯定是把ID作为参数给传过去,通过路径参数)
请求方式:get
请求路径:/admin/dish/{id}
请求参数:路径参数(记得加注解@PathVariable)
返回资料:data,code
②根据类型查询分类(已实现,在新增那)
③文件上传(已建立,在新增那)
④修改菜品
请求路径:put
请求方式:/admin/dish
请求参数:请求体(json格式)<通过请求体来提交到后端>
返回参数:code(必须)
二、代码开发
1.一个接口
●查询菜品(返回的是DishVO,包括我们的菜品表和口味表)
●在service的impl层:
①根据ID查询菜品数据
②根据菜品ID查询口味数据(因为一个菜品可能会对应多个口味,于是返回的是一个list集合,泛形是DishFlavor)
③将查询到的材料封装到DishVO(先把该对象给new出来,接着通过对象属性拷贝BeanUtils.copyProperties(dish,dishVO),然后再把口味那个设置进去就可以了.setFlavors)
2.第二个接口
●修改菜品(他的途径不用写泛型)
●先来删除原先的口味数据,再插入,最终达到修改的一个效果
●service impl层
①修改菜品表基本信息
因为DTO里面关联着口味数据,所以我们新new一个dish对象,接着再借助对象的属性拷贝(BeanUtils.copyProperties(dishDTO,dish)),把DTO里面的内容拷贝到dish里面
②删除原有的口味数据
③重新插入口味内容
三、功能测试
●通过前后端联调测试
●测试完成之后提交并推送
店铺营业状态设置
●商家管理端页面
当点击管理端右上角的营业状态设置时,会弹出两个选项,一个是营业中,一个是打烊中(这个窗口当中,我们就可以设置营业状态)
⭐如果把营业状态设置为打烊中,则用户在小程序端是不能够点餐的,就会在小程序端显示休息中,并且在下方显示本店已打烊
⭐不过在开发该业务之前,需要学习一些前置的知识(Redis(这个Redis其实也是一个数据库,用来存储数据))
浙公网安备 33010602011771号