SpringBoot项目实战：手把手教你搞定苍穹外卖的套餐管理CRUD（附完整代码）
SpringBoot实战：深度解析苍穹外卖套餐管理模块的设计与实现
在当今快节奏的外卖行业，一套高效稳定的后台管理系统是业务运转的核心支柱。作为Java开发者，掌握如何构建这样的系统不仅能提升技术实力，更能理解真实商业场景下的技术决策。本文将带您从零开始，实现一个完整的套餐管理模块，涵盖从数据库设计到前端交互的全流程。
1. 项目架构与核心设计
1.1 数据库模型设计
套餐管理涉及两个核心实体：setmeal（套餐主表）和setmeal_dish（套餐菜品关联表）。这种设计遵循了数据库第三范式，避免了数据冗余：
CREATE TABLE `setmeal` ( `id` bigint NOT NULL AUTO_INCREMENT, `category_id` bigint NOT NULL COMMENT '分类id', `name` varchar(32) NOT NULL COMMENT '套餐名称', `price` decimal(10,2) NOT NULL COMMENT '套餐价格', `status` int DEFAULT NULL COMMENT '状态 0:停用 1:启用', `description` varchar(255) DEFAULT NULL COMMENT '描述信息', `image` varchar(255) DEFAULT NULL COMMENT '图片', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, `create_user` bigint DEFAULT NULL, `update_user` bigint DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `idx_name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COMMENT='套餐'; CREATE TABLE `setmeal_dish` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `setmeal_id` bigint NOT NULL COMMENT '套餐id', `dish_id` bigint NOT NULL COMMENT '菜品id', `name` varchar(32) DEFAULT NULL COMMENT '菜品名称', `price` decimal(10,2) DEFAULT NULL COMMENT '菜品单价', `copies` int DEFAULT NULL COMMENT '份数', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COMMENT='套餐菜品关系';关键设计考虑：
- 套餐名称设置唯一索引，避免重复
- 价格使用DECIMAL类型保证精确计算
- 状态字段使用枚举值便于维护
- 关联表记录菜品单价，避免价格变动影响历史订单
1.2 领域模型设计
采用DTO模式进行层次隔离：
// 套餐DTO public class SetmealDTO extends Setmeal { private List<SetmealDish> setmealDishes; // getters & setters } // 套餐VO public class SetmealVO extends Setmeal { private String categoryName; private List<SetmealDish> setmealDishes; // getters & setters }这种设计实现了：
- Setmeal：基础实体，对应数据库表
- SetmealDTO：数据传输对象，用于前后端交互
- SetmealVO：视图对象，包含关联数据
2. 核心功能实现
2.1 新增套餐：事务处理的艺术
新增套餐需要同时操作套餐表和关联表，必须保证事务一致性：
@Transactional public void saveWithDish(SetmealDTO setmealDTO) { // 1. 保存套餐基本信息 Setmeal setmeal = new Setmeal(); BeanUtils.copyProperties(setmealDTO, setmeal); setmealMapper.insert(setmeal); // 2. 保存套餐菜品关系 Long setmealId = setmeal.getId(); List<SetmealDish> dishes = setmealDTO.getSetmealDishes() .stream() .peek(dish -> dish.setSetmealId(setmealId)) .collect(Collectors.toList()); setmealDishMapper.insertBatch(dishes); }关键点解析：
@Transactional注解确保操作原子性- 使用BeanUtils简化对象拷贝
- 批量插入优化性能（对比单条插入）
- 获取自增ID的两种方式比较：
useGeneratedKeys（推荐）SELECT LAST_INSERT_ID()
2.2 分页查询：MyBatis动态SQL实战
套餐分页需要支持多条件筛选：
<select id="pageQuery" resultType="com.sky.vo.SetmealVO"> SELECT s.*, c.name categoryName FROM setmeal s LEFT JOIN category c ON s.category_id = c.id <where> <if test="name != null"> AND s.name LIKE CONCAT('%', #{name}, '%') </if> <if test="categoryId != null"> AND s.category_id = #{categoryId} </if> <if test="status != null"> AND s.status = #{status} </if> </where> ORDER BY s.create_time DESC </select>性能优化技巧：
- 避免在LIKE中使用前置通配符
- 大表分页建议使用
WHERE id > ? LIMIT ?替代LIMIT ?, ? - 关联查询字段建立合适索引
2.3 删除套餐：业务规则校验
删除操作需要处理关联数据并校验业务状态：
@Transactional public void deleteBatch(List<Long> ids) { // 校验套餐是否在售 ids.forEach(id -> { Setmeal setmeal = setmealMapper.getById(id); if (setmeal.getStatus() == StatusConstant.ENABLE) { throw new BusinessException("起售中的套餐不可删除"); } }); // 删除套餐及关联菜品 ids.forEach(id -> { setmealMapper.deleteById(id); setmealDishMapper.deleteBySetmealId(id); }); }防御性编程要点：
- 先校验后操作原则
- 异常处理要明确错误原因
- 批量操作考虑数据量过大时的分片处理
3. 进阶功能实现
3.1 套餐状态管理
起售/停售需要校验关联菜品状态：
public void startOrStop(Integer status, Long id) { if (status == StatusConstant.ENABLE) { List<Dish> dishes = dishMapper.getBySetmealId(id); dishes.stream() .filter(dish -> dish.getStatus() == StatusConstant.DISABLE) .findAny() .ifPresent(dish -> { throw new BusinessException("套餐包含未启售菜品"); }); } setmealMapper.update(Setmeal.builder() .id(id) .status(status) .build()); }状态机设计模式：
- 使用枚举定义状态常量
- 状态转换前置校验
- 考虑引入状态模式处理复杂状态流转
3.2 缓存优化策略
高并发场景下的缓存设计方案：
@Cacheable(value = "setmeal", key = "#id") public SetmealVO getByIdWithCache(Long id) { return getByIdWithDish(id); } @CacheEvict(value = "setmeal", key = "#setmealDTO.id") public void updateWithCache(SetmealDTO setmealDTO) { update(setmealDTO); }缓存策略对比：
| 策略 | 适用场景 | 优缺点 |
|---|---|---|
| Cache-Aside | 读多写少 | 实现简单，但存在缓存穿透风险 |
| Write-Through | 写操作频繁 | 数据强一致，但写入延迟高 |
| Write-Behind | 高吞吐场景 | 性能最佳，但可能丢失数据 |
4. 异常处理与日志监控
4.1 自定义异常体系
public class BusinessException extends RuntimeException { private final ErrorCode errorCode; public BusinessException(ErrorCode errorCode) { super(errorCode.getMessage()); this.errorCode = errorCode; } } public enum ErrorCode { SETMEAL_NOT_FOUND(40401, "套餐不存在"), SETMEAL_ON_SALE(40001, "套餐正在售卖中"); private final int code; private final String message; // constructor & getters }异常处理最佳实践：
- 区分业务异常和系统异常
- 异常信息包含足够上下文
- 避免直接暴露堆栈信息
4.2 操作日志记录
使用AOP实现无侵入式日志：
@Aspect @Component @Slf4j public class OperationLogAspect { @Around("@annotation(operationLog)") public Object around(ProceedingJoinPoint pjp, OperationLog operationLog) { long start = System.currentTimeMillis(); try { Object result = pjp.proceed(); log.info("[操作成功] {} 耗时: {}ms", operationLog.value(), System.currentTimeMillis() - start); return result; } catch (Throwable e) { log.error("[操作失败] {}", operationLog.value(), e); throw e; } } }日志监控指标：
- 接口响应时间P99
- 错误率
- 关键操作频次
在实际开发中，我发现套餐管理的难点不在于CRUD实现，而在于如何处理各种边界条件和保证数据一致性。例如批量删除时，部分成功部分失败的情况如何处理？我的经验是采用"预检查+事务补偿"机制：先进行全面的业务校验，确保所有记录都符合删除条件后再执行操作，如果中途失败则记录失败明细并提供重试机制。