作为一个在餐饮行业摸爬滚打多年的技术负责人,我深知传统火锅店管理面临的痛点:手工记录订单易出错、库存盘点耗时费力、员工排班混乱、顾客反馈难以追踪。为了解决这些问题,我们团队开发了这套基于SpringBoot的火锅店管理系统。
这个系统采用B/S架构,前端使用Vue.js,后端基于SpringBoot框架,数据持久层采用MyBatisPlus,数据库使用MySQL。系统主要包含以下核心功能模块:
我们选择SpringBoot作为后端框架主要基于以下考虑:
核心依赖配置示例:
xml复制<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.5.3</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>
</dependencies>
Vue.js作为前端框架的优势:
典型组件结构:
javascript复制<template>
<div class="order-list">
<el-table :data="orders">
<el-table-column prop="orderNo" label="订单号"></el-table-column>
<el-table-column prop="createTime" label="下单时间"></el-table-column>
</el-table>
</div>
</template>
<script>
export default {
data() {
return {
orders: []
}
},
created() {
this.fetchOrders()
},
methods: {
async fetchOrders() {
const res = await this.$http.get('/api/orders')
this.orders = res.data
}
}
}
</script>
MyBatisPlus在项目中发挥了重要作用:
实体类与Mapper示例:
java复制@Data
@TableName("t_order")
public class Order {
@TableId(type = IdType.AUTO)
private Long id;
private String orderNo;
private Integer status;
// 其他字段...
}
public interface OrderMapper extends BaseMapper<Order> {
@Select("SELECT * FROM t_order WHERE create_time >= #{startTime}")
List<Order> selectAfterDate(@Param("startTime") Date startTime);
}
订单流程设计要点:
订单状态机:定义了从创建到完成的完整状态流转
库存预扣减:下单时预占库存,避免超卖
java复制@Transactional
public Order createOrder(OrderDTO dto) {
// 校验库存
List<InventoryLock> locks = checkInventory(dto.getItems());
// 创建订单
Order order = convertToOrder(dto);
orderMapper.insert(order);
// 扣减库存
updateInventory(locks);
return order;
}
智能库存管理实现方案:
库存检查定时任务:
java复制@Scheduled(cron = "0 0 9 * * ?")
public void checkInventory() {
List<Material> materials = materialMapper.selectList(null);
materials.stream()
.filter(m -> m.getStock() < m.getSafeStock())
.forEach(this::sendAlert);
}
基于RBAC的权限设计:
权限拦截器核心逻辑:
java复制@Override
public boolean preHandle(HttpServletRequest request,
HttpServletResponse response,
Object handler) {
// 放行OPTIONS请求
if (request.getMethod().equals("OPTIONS")) {
return true;
}
// 检查注解
IgnoreAuth annotation = getAnnotation(handler);
if (annotation != null) {
return true;
}
// 验证Token
String token = request.getHeader("Token");
TokenEntity tokenEntity = tokenService.getTokenEntity(token);
if (tokenEntity == null) {
sendError(response, "请先登录");
return false;
}
// 存储用户信息
request.setAttribute("userId", tokenEntity.getUserId());
return true;
}
我们采用分层测试策略:
登录功能测试矩阵:
| 测试场景 | 输入数据 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常登录 | 正确账号密码 | 登录成功 | 通过 |
| 错误密码 | 正确账号+错误密码 | 提示密码错误 | 通过 |
| 空用户名 | 用户名为空 | 提示必填 | 通过 |
| 权限校验 | 普通员工登录管理端 | 拒绝访问 | 通过 |
库存预警测试要点:
针对测试发现的性能瓶颈,我们做了以下优化:
推荐部署方案:
Dockerfile示例:
dockerfile复制FROM openjdk:11-jre
COPY target/hotpot-system.jar /app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]
在实际开发过程中,我们积累了一些宝贵经验:
未来可能的扩展方向:
这个项目让我深刻体会到,一个好的餐饮管理系统不仅要技术过关,更要深入理解业务场景。比如在库存预警中,我们最初只考虑了静态安全库存,后来加入了季节性因素和促销预测,才真正解决了客户的痛点。