《苍穹外卖》套餐管理核心业务代码精讲【从零到一实战解析】

1. 从零理解《苍穹外卖》套餐管理架构第一次接触《苍穹外卖》项目时最让我头疼的就是套餐管理模块的业务逻辑。这个模块看似简单实际涉及Controller、Service、Mapper三层协作还有复杂的菜品关联关系。经过三个版本的迭代优化我总结出这套最清晰的代码结构。先看整体架构图前端请求通过SetmealController进入系统调用SetmealService处理核心业务逻辑最终由SetmealMapper和SetmealDishMapper操作数据库。关键点在于套餐与菜品的关联关系处理这直接影响到新增、修改、查询等核心功能。举个例子当用户创建包含5道菜的套餐时系统需要在setmeal表插入套餐基础信息获取自动生成的套餐ID在setmeal_dish表批量插入5条关联记录这种主表关联表的设计模式非常经典但新手常犯的错误是忘记处理事务。比如插入套餐成功但关联菜品失败时如果没有事务管理就会导致数据不一致。我们在ServiceImpl中使用的Transactional注解就是解决这个问题的关键。2. 新增套餐的完整实现解析2.1 Controller层设计要点SetmealController的代码看似简单但有几个设计细节值得注意PostMapping public Result save(RequestBody SetmealDTO setmealDTO){ setmealService.saveWithSetmealDish(setmealDTO); return Result.success(); }这里使用SetmealDTO接收前端数据而不是直接使用Entity对象这是遵循了DTO设计模式。DTO可以包含套餐基础信息和菜品列表避免了多次请求。我曾在早期版本中使用两个独立接口分别保存套餐和菜品结果前端调用变得非常复杂。日志记录也很有讲究log.info(新增套餐:{},setmealDTO)这行代码会在控制台输出完整的请求数据。建议开发阶段保持这个习惯排查问题时能快速定位到具体数据。2.2 Service层事务处理实战ServiceImpl中的saveWithSetmealDish方法是核心中的核心Transactional public void saveWithSetmealDish(SetmealDTO setmealDTO) { // 转换DTO为Entity Setmeal setmeal new Setmeal(); BeanUtils.copyProperties(setmealDTO,setmeal); // 设置默认状态 setmeal.setStatus(StatusConstant.ENABLE); // 插入套餐主表 setmealMapper.insert(setmeal); // 处理关联菜品 Long setmealId setmeal.getId(); ListSetmealDish setmealDishes setmealDTO.getSetmealDishes(); setmealDishes.forEach(dish - dish.setSetmealId(setmealId)); // 批量插入关联表 setmealDishMapper.insertBatch(setmealDishes); }这里有几个技术要点BeanUtils.copyProperties实现对象属性拷贝比手动set更简洁状态字段设置默认值避免前端遗漏获取自增主键后立即设置到关联对象中使用批量插入提高性能特别注意Transactional注解要加在public方法上才有效。曾经有同事把它加在private方法上调试了半天才发现事务没生效。2.3 Mapper层SQL优化技巧MyBatis的XML映射文件中有几个值得学习的写法insert idinsert useGeneratedKeystrue keyPropertyid insert into setmeal(...) values (...) /insertuseGeneratedKeys和keyProperty配合使用可以自动回填自增ID这是获取主键的标准做法。早期版本我曾在插入后立即执行select last_insert_id()查询既麻烦又存在并发问题。批量插入的SQL也很有讲究insert idinsertBatch insert into setmeal_dish values foreach collectionlist itemitem separator, (#{item.setmealId},#{item.dishId},...) /foreach /insert这种写法比循环执行单条insert语句效率高10倍以上。当套餐包含20个菜品时执行时间从200ms降到20ms左右。注意values后面的逗号分隔符要和foreach的separator保持一致。3. 套餐分页查询的进阶实现3.1 动态SQL构建技巧分页查询最大的特点是条件动态变化MyBatis的动态SQL完美解决了这个问题select idpageQuery resultTypecom.sky.entity.Setmeal select * from setmeal where if testname ! null and name ! and name like concat(%,#{name},%) /if if testcategoryId ! null and category_id #{categoryId} /if if teststatus ! null and status #{status} /if /where order by update_time desc /select这里的where标签会自动处理条件前缀的and/or问题。记得有次我直接在SQL里写where 11被技术主管指出这是不良实践。正确的做法是使用where标签它能智能处理以下情况无条件时自动移除where关键字有条件时自动去除第一个and/or模糊查询使用concat函数比直接拼接更安全可以避免SQL注入问题。排序字段建议使用update_time而不是create_time这样最新修改的套餐会排在前面。3.2 分页参数处理方案Controller接收的分页参数是这样的GetMapping(/page) public ResultPageResult page(SetmealPageQueryDTO dto){ PageResult result setmealService.pageQuery(dto); return Result.success(result); }Service层使用PageHelper实现物理分页public PageResult pageQuery(SetmealPageQueryDTO dto) { PageHelper.startPage(dto.getPage(), dto.getPageSize()); PageSetmeal page setmealMapper.pageQuery(dto.getName(),...); return new PageResult(page.getTotal(), page.getResult()); }这里容易踩的坑是PageHelper的startPage必须紧挨着Mapper调用中间不能有其他SQL查询否则分页会失效。建议在Service方法开头就启动分页避免意外插入其他数据库操作。4. 批量删除的业务逻辑深度剖析4.1 状态校验的必要性删除套餐前必须检查是否处于启售状态这是典型的业务规则校验public void delete(ListLong ids) { ListSetmeal setmeals setmealMapper.getById(ids); setmeals.forEach(setmeal - { if (setmeal.getStatus() StatusConstant.ENABLE) { throw new DeletionNotAllowedException(套餐正在售卖中); } }); // 执行删除操作 setmealMapper.deleteBatch(ids); setmealDishMapper.deleteBatch(ids); }这里使用先查询再判断的方式虽然多了一次查询但保证了数据一致性。曾经尝试过直接在delete语句中添加status条件但会导致部分成功部分失败的情况不利于给用户明确反馈。异常消息使用常量定义是个好习惯比如MessageConstant.SETMEAL_ON_SALE。这样修改提示文本时只需改一个地方还能支持国际化。4.2 批量删除的SQL优化关联表的批量删除SQL值得学习delete iddeleteBatch delete from setmeal_dish where setmeal_id in foreach collectionids itemid open( close) separator, #{id} /foreach /delete这种in语句的批量删除方式比循环执行单条delete效率高得多。当删除100个套餐时执行时间从2秒降到0.1秒左右。注意参数名ids要和Mapper接口中的参数名完全一致否则会报绑定异常。5. 套餐修改的完整流程解析5.1 先删后增的关联处理策略修改套餐的特殊之处在于需要先删除旧关联再建立新关联public void update(SetmealDTO setmealDTO) { // 更新主表 Setmeal setmeal new Setmeal(); BeanUtils.copyProperties(setmealDTO, setmeal); setmealMapper.update(setmeal); // 处理关联菜品 Long setmealId setmealDTO.getId(); setmealDishMapper.deleteBySetmealId(setmealId); ListSetmealDish dishes setmealDTO.getSetmealDishes(); dishes.forEach(dish - dish.setSetmealId(setmealId)); setmealDishMapper.insertBatch(dishes); }这种模式虽然会产生额外的删除操作但实现简单且不易出错。替代方案是比对新旧菜品列表只增删变化的部分但代码复杂度会大幅增加。对于菜品数量不超过50的套餐来说直接全量替换是更合理的选择。5.2 MyBatis动态更新语法主表更新使用了动态字段处理update idupdate update setmeal set if testcategoryId ! nullcategory_id#{categoryId},/if if testname ! nullname#{name},/if ... /set where id#{id} /updateset标签会自动去除末尾的逗号比手动拼接set语句更优雅。注意每个条件判断要周全比如字符串字段既要判null又要判空字符串否则可能导致意外清空字段。6. 启停状态的业务规则实现6.1 嵌套查询的性能考量启售套餐时需要检查包含的菜品是否都已启售public void startOrStop(Integer status, Long id) { if (status StatusConstant.ENABLE) { ListDish dishes dishMapper.getBySetmealId(id); dishes.forEach(dish - { if (dish.getStatus() StatusConstant.DISABLE) { throw new SetmealEnableFailedException(包含未启售菜品); } }); } // 更新状态 setmealMapper.update(Setmeal.builder() .status(status) .id(id) .build()); }这里通过left join一次性查询出所有关联菜品比循环查询效率更高。Builder模式创建实体对象比newsetter更简洁特别是在只更新部分字段时。6.2 状态枚举的最佳实践状态常量定义成枚举类更规范public enum Status { ENABLE(1, 启售), DISABLE(0, 停售); private final int code; private final String desc; // 构造方法、getter省略 }相比直接使用魔法数字1和0枚举类型更安全易懂。系统中有5处状态判断使用枚举后代码可读性明显提升修改状态值时也只需改一个地方。