基于SSM框架的酒店管理系统：整合、动态SQL与事务管理实战

简介基于SSM框架的酒店管理系统设计与实现资源面向Java Web学习者、毕业设计及课程设计人群提供从后端框架整合到数据库设计的完整参考解决系统开发中涉及客房、订单、客户等业务模块的落地问题。压缩包共3个文件项目源码zip包、数据库SQL脚本、设计文档doc整体大小约23.62MB源码涵盖Spring、SpringMVC、MyBatis三框架整合及Mapper配置SQL脚本包含酒店信息、客房类型、订单、客户等核心数据表设计文档补充需求分析与系统设计说明。已有493人学习/浏览适合需要快速搭建酒店管理项目或撰写相关论文的开发者。借助这套资源读者可掌握SSM项目分层结构、数据库表关联设计、业务控制流程以及常见安全性考虑兼具参考与练手价值。1. 基于SSM框架的酒店管理系统为什么课程设计和工程落地都绕不开它基于SSM框架的酒店管理系统是把Spring、SpringMVC、MyBatis这三个Web开发核心组件压缩到一个真实业务场景里的最佳载体。酒店业务本身并不复杂用户注册、房间查询、下订单、入住退房、订单记录查询每一项都对应数据库中最典型的增删改查操作却又不只是单表读写——房间状态和订单状态之间的联动、会员与订单的关联查询、按不同条件筛选房间列表这些正好覆盖了数据库课程设计阶段应该掌握的全部细节。对于正在做课程设计或者准备面试的人来说这个系统的价值在于你不需要从零设计业务规则但你必须把SSM框架的整合流程、配置文件的组织和事务边界一次弄明白。架构、数据库、业务实现、部署排错四条线在下面依次展开直接对应一套工程化SSM项目最常被问到的环节。2. 从SSM框架的整合讲起分层职责与最小可运行配置2.1 三个框架各管哪一层边界不清时项目会烂在哪Spring 容器层、SpringMVC 表现层、MyBatis 持久层这三层的职责拆分明细可以先规范化框架负责的层面核心机制Spring业务Bean管理与事务边界IoC、AOP、TransactionalSpringMVC请求路由与控制编排DispatcherServlet、HandlerMapping、RequestMappingMyBatisSQL执行与结果映射Mapper接口、XML映射文件、动态SQL一次酒店管理系统的请求在执行过程中会经历上述三层浏览器发出“查询空闲房间”的请求后SpringMVC 的 DispatcherServlet 把请求转发给 RoomControllerController 调用 RoomService 接口Service 实现类里开启事务并调用 RoomMapper 接口RoomMapper 通过 MyBatis 映射文件里的 SQL 从 t_room 表返回结果集最终这条数据被包装成统一 Result 对象回传页面。认清这个调用链的价值在于功能报错的时候能准确定位排查范围——页面报 500 去查 Controller 层参数绑定数据不对去查 SQL事务不回滚去查 Service 层注解。分层的常见错误是过度依赖 MyBatis 自动映射。如果数据库字段是 room_type实体类是 roomTypeMyBatis 默认开启驼峰映射后可以正确匹配但如果数据库字段和实体类都叫 room_typeJSON 序列化给前端时键名就成了小写下划线风格前端取值会得到 undefined。所以在数据库设计时就要决定命名风格我一般统一用下划线命名数据库字段实体类用驼峰并在 MyBatis 配置里打开 mapUnderscoreToCamelCase。Controller 里只出现路由注解、参数接收、调用 Service、结果封装这四件事。下面的返回结构是整套系统的统一响应协议理解它再往后看代码就不会晕public class Result { private Integer code; // 200 成功500 业务失败 private String msg; private MapString, Object data; public static Result success(String key, Object value) { Result r new Result(); r.setCode(200); r.setMsg(ok); r.data new HashMap(); r.data.put(key, value); return r; } public static Result fail(String msg) { Result r new Result(); r.setCode(500); r.setMsg(msg); return r; } // 省略 getter/setter }这里用 Map 承载数据是出于扩展性的考虑房间列表页面需要同时返回房间集合和分页总条数如果 data 直接定义为 List后面要追加 total 字段就得改协议。code 字段的语义是成功或失败msg 对应失败原因的展示文本前端发请求时先判断 code 再决定渲染逻辑可以省去整页刷新后的兜底分支。需要注意的是 Map 里存的 value 不能为 null否则 JSON 序列化会直接丢掉这个键前端解构时得到 undefined。2.2 最小 Maven 依赖组合与版本兼容边界SSM 整合最大的痛点是版本矩阵。Spring 5.x 与 Spring 4.x 的配置差异、mybatis 与 mybatis-spring 的对应关系、MySQL 驱动版本对连接 URL 的要求这几条变量叠加起来往往导致源码导入后根本无法启动。我建议固化一套稳定组合Spring 5.3.x MyBatis 3.5.x mybatis-spring 2.0.x MySQL 8.0 驱动。dependencies dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.3.21/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-jdbc/artifactId version5.3.21/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version3.5.10/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.0.7/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.29/version scoperuntime/scope /dependency /dependencies依赖版本说明按经验排序第一个要锁定的是 mybatis-spring它的版本兼容性最敏感2.0.7 对应 mybatis 3.5.x 没问题mybatis 升到 3.5.9 以上就要回归测试一遍。第二个是 spring-jdbc 与 spring-tx它们与 spring-webmvc 的版本号必须完全一致混合版本运行时会出现 Bean 创建失败。第三个是 mysql-connector-java8.x 驱动要求连接串携带 serverTimezone 参数且必须显式写明 useSSLfalse否则启动时第一次初始化数据源就会抛异常。提示依赖下载慢时可以使用阿里云 Maven 镜像但注意把 mirrorOf 设置成 central 而不是 *全量代理会让部分冷门仓库超时。2.3 applicationContext 与 SpringMVC 配置文件怎么拆SSM 框架下有两份核心配置applicationContext.xml 管理数据源、事务、Service 和 MapperDispatcherServlet 加载的 springmvc-config.xml 管理 Controller、视图解析和 JSON 转换。如果全部塞进一份文件启动时通常不出问题但 Controller 里调用 Service 实现类时事务代理可能因为容器归属问题静默失效。applicationContext.xml 的片段context:component-scan base-packagecom.hotel context:exclude-filter typeannotation expressionorg.springframework.stereotype.Controller/ /context:component-scan bean iddataSource classcom.alibaba.druid.pool.DruidDataSource init-methodinit destroy-methodclose property namedriverClassName value${jdbc.driver}/ property nameurl value${jdbc.url}/ property nameusername value${jdbc.username}/ property namepassword value${jdbc.password}/ /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/*.xml/ property nameconfiguration bean classorg.apache.ibatis.session.Configuration property namemapUnderscoreToCamelCase valuetrue/ /bean /property /bean用排除过滤把 Controller 注解挡在 Spring 父容器之外目的是让 MVC 子容器持有 Controller父容器持有 Service与前面的分层思路对应。mapperLocations 指向 classpath:mapper/*.xml要求 XML 文件必须位于 resources/mapper 目录否则调用 Mapper 方法时会出现 Invalid bound statement。mapUnderscoreToCamelCase 打开后下面的 SQL 不用再为每个字段取别名。springmvc-config.xml 里再补一段mvc:annotation-driven/ context:component-scan base-packagecom.hotel.controller/ mvc:resources mapping/static/** location/static//mvc:resources 这行是解决“页面能打开但 CSS/JS 加载不出来”的关键它对 /static 路径做静态资源放行不然 DispatcherServlet 会把所有路径都交给 Controller 路由。使用 ResponseBody 时 Spring 会通过消息转换器把返回对象转成 JSON只要 jackson-databind 依赖存在接口层基本不需要手动拼 JSON。这套配置就绪后数据库部分可以直接进入第3章的建模。3. 酒店管理系统数据库建模核心表结构与 MyBatis 动态查询3.1 用户、房间、订单三张核心表怎么建先给出一组数据库设计中的核心表清单。酒店管理系统的数据表一般按业务模块划分权限与用户模块、房间模块、订单模块、日志模块。最小交付集合是 6 张表其中三张是核心业务表三张是支撑表用户表t_user、房间表t_room、订单表t_order、房间类型表t_room_type、订单状态日志表t_order_log、操作日志表t_action_log。表名用途关键字段t_user用户与管理员账号id, username, password, phone, user_typet_room房间基本信息id, room_no, room_type, price, floor, statust_order预订与入住记录id, order_no, user_id, room_id, check_in_date, check_out_date, total_price, order_statust_room_type房型分类id, type_name, base_price, capacityt_order_log订单状态变更历史id, order_id, from_status, to_status, change_time, change_byt_action_log操作行为记录id, user_id, action, detail, create_time用户表里面 user_type 不要用 String 存 admin、user 这类文字用 TINYINT 存数值并在 Java 枚举里定义常量存储空间小且索引效率高是和 MyBatis 的门面清晰对接。订单表把 user_id 和 room_id 作为外键关联用户、房间表order_no 用业务编号而非自增 id避免向用户暴露订单量。CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id INT NOT NULL, room_id INT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, total_price DECIMAL(10,2) NOT NULL DEFAULT 0, order_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已入住 2已完成 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES t_user(id), CONSTRAINT fk_order_room FOREIGN KEY (room_id) REFERENCES t_room(id), INDEX idx_order_status (order_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;设计原理需要解释清楚。订单状态查询是核心业务如果没有 idx_order_status 索引订单列表页在数据量上来后会全表扫描加上单列索引后按状态筛选的代价大幅下降。total_price 在订单生成时由 Service 层计算并写入而不是每次都用价格乘以天数现场计算因为历史订单的金额不应受房间调价影响。建表语句里 ORDER 是 MySQL 保留字所以表名使用 t_order 加前缀是业界已经验证过的避坑方式。3.2 多条件房间查询时的 MyBatis 动态 SQL 写法管理端的房间管理页面通常有这些筛选条件房型、楼层、价格区间、房间状态。把参数传进 Select 方法在 RoomMapper.xml 中用 where 与 if 控制拼接select idselectRoomByCondition parameterTypemap resultTypecom.hotel.pojo.Room SELECT id, room_no, room_type, price, floor, status FROM t_room where if testroomType ! null and roomType ! AND room_type #{roomType} /if if testfloor ! null AND floor #{floor} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if if teststatus ! null AND status #{status} /if /where ORDER BY floor ASC, room_no ASC /select参数说明一并写出来。roomType 是 String非空判断要同时写 null 和空串floor、minPrice、maxPrice、status 用 Integer 包装类型只判断 null 即可。用 int 基本类型作为入参会有一个隐藏问题值为 0 时条件判断永远成立。比如“查询空闲房间 status0”这个请求如果 Mapper 形参是基本类型 intif 表达式永远为 true状态条件会被拼进去反过来说在动态 SQL 里期望忽略某个条件时包装类型为 null 才能触发跳过。所以 Mapper 接口建议用 Map 封装多个参数。MyBatis 的早期版本会缓存部分已解析的 SQL修改 XML 后需要重启才会生效排查“改了 SQL 但没变化”的故障时可以直接往缓存的方向检查。3.3 数据库初始化脚本与连接参数对齐用仓库里的 sql 文件导入后数据库课程设计部分就完成了大半。同步执行 sql 文件时我习惯用命令行而非图形工具减少字符集不一致带来的干扰mysql -u root -p hotel_db.sql导入完成后先执行SHOW TABLES;验证表数量再执行SELECT COUNT(*) FROM t_room;检查初始数据是否真的进库。这里有一个常见疏忽sql 文件里的库名、用户名、密码、端口号四个值必须与 jdbc.properties 里的配置完全对齐。MySQL 8.x 下的连接串建议写成jdbc:mysql://localhost:3306/hotel_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai其中比较关键的是 serverTimezone它决定日期时间类型的读写时区useSSL 设为 false 是为了避免握手阶段报证书错误。改连接参数时容易只改一处、漏改另一处两份配置同时核对才能顺利跑通登录模块。4. 酒店管理系统的核心业务实现登录、下订单与状态联动4.1 登录校验接口与未登录拦截的实现Controller 层的登录接口是三层架构见真章的地方——Controller 不直接操作数据库而是把参数传给 Service由 Service 返回结果。这里展示一个标准写法RestController RequestMapping(/api/user) public class UserController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody LoginDTO dto, HttpSession session) { User user userService.validate(dto.getUsername(), dto.getPassword()); if (user null) { return Result.fail(用户名或密码错误); } session.setAttribute(CURRENT_USER, user); return Result.success(user, user); } }参数说明RequestBody 把前端传来的 JSON 反序列化成 LoginDTO 对象HttpSession 通过 SpringMVC 的方法参数解析器直接从容器拿不需要手动从 request 里取值把整个 user 对象放进 session是为了后续拦截器获取当前用户信息。常见的坏味道是 Controller 里写一堆判断逻辑比如先查用户名再比对密码这些应该在 Service 层完成。后续要加登录限流时也需要在拦截器里统一处理Controller 保持轻量。配套的拦截器要注册到 springmvc 配置里public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); if (session.getAttribute(CURRENT_USER) null) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登录\}); return false; } return true; } }preHandle 返回 false 时请求链路被中断不会进入 Controller。这里直接把 401 JSON 字符串写到响应体比 redirect 到登录页更符合前后端分离的场景。注册拦截器时注意排除登录接口和静态资源路径否则会出现“登录接口被拦截器拦截导致循环跳转”的经典报错。当后端返回 401 而前端还停留在旧页面时拦截器路径配置错误是第一排查对象。4.2 带事务的订单创建 Service 写法订单创建是整套系统里最值得展开的部分。表面看是往 t_order 表插一条记录实际涉及三处数据变更订单表插入、房间状态由空闲改为已占用、订单日志插入。这三步是一个原子操作任何一步失败都要回滚。Transactional 注解放在 Service 实现类上Service public class OrderServiceImpl implements OrderService { Autowired private OrderMapper orderMapper; Autowired private RoomMapper roomMapper; Autowired private OrderLogMapper orderLogMapper; Override Transactional(rollbackFor Exception.class) public Order createOrder(OrderCreateDTO dto) { Room room roomMapper.selectById(dto.getRoomId()); if (room null || room.getStatus() ! 0) { throw new OrderException(房间不存在或已被预订); } Order order new Order(); order.setOrderNo(R System.currentTimeMillis() RandomUtil.randomNumbers(4)); order.setUserId(dto.getUserId()); order.setRoomId(dto.getRoomId()); order.setCheckInDate(dto.getCheckInDate()); order.setCheckOutDate(dto.getCheckOutDate()); order.setOrderStatus(0); orderMapper.insert(order); Room updateRoom new Room(); updateRoom.setId(dto.getRoomId()); updateRoom.setStatus(1); roomMapper.updateById(updateRoom); OrderLog log new OrderLog(); log.setOrderId(order.getId()); log.setFromStatus(-1); log.setToStatus(0); log.setChangeBy(dto.getUserId()); orderLogMapper.insert(log); return order; } }这个方法的三个细节值得仔细看。其一rollbackFor Exception.class 必须显式声明默认情况下 Spring 只对 RuntimeException 和 Error 回滚如果自定义 OrderException 继承自 Exception事务将完全失效订单插进去了而房间状态没改系统会漂出脏数据。其二房间状态检查放在事务一开始并发场景下两个请求同时读到 status0第二笔事务会在 update 阶段卡住需要在 t_room 表加乐观锁版本号或对 status 做条件更新UPDATE t_room SET status1 WHERE id? AND status0返回 0 行即表示已被抢。其三订单金额在生成时快照查询时不再关联房间价格应付“价格变了旧订单金额不该变”的需求。4.3 订单状态流转与前端按钮联动订单状态的取值在数据库里是 TINYINT到了 Java 应该对应一个枚举避免业务里到处是魔法数public enum OrderStatus { UNPAID(0, 待支付), CHECKED_IN(1, 已入住), FINISHED(2, 已完成), CANCELED(3, 已取消); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } // getter 省略 }前端根据后端返回的 orderStatus 数值渲染按钮状态变更的每个分支都应该有权限控制待支付订单只能由下单人支付已入住订单只能由运营端退房已完成订单不可再操作。这些校验的收口位置体现架构功底——如果散落在 JSP 或各页面的 if 判断里项目会越改越乱把它收拢到 Service 的一个 changeOrderStatus 方法里做集中 switch是这套系统最值得复用的设计。前端配合的写法是根据状态映射按钮组const statusActions { 0: [支付, 取消], 1: [退房, 续住], 2: [], 3: [删除] }; renderButtons(statusActions[order.orderStatus]);这段逻辑说明订单状态决定页面按钮组合后端只返回数字状态码前端用一个字典映射动作集合替换掉散落在各页面里的 if-else 判断。退房动作触发时前端把 orderId 传回后端Service 侧把订单状态改为 2、把房间状态改为 2清洁中再写一条操作日志。状态机是这套系统里最典型的非 CRUD 业务设计答辩时讲清楚同一张表的两个字段如何联动基本能证明对数据库设计和业务建模的掌握程度。5. 部署、排错与验收把 SSM 酒店管理系统完整跑起来5.1 初始化数据库与修改连接配置一份基于 SSM 框架的酒店管理系统交付包通常包含源码、数据库脚本和设计文档三部分开箱可运行的关键在三个来源的同步数据库初始化文件里的库名、jdbc.properties 里的连接参数、Web 容器运行时实际连接的库必须一致。任何一端不一致启动时往往不报错第一次查询就提示找不到表或连接失败。先把 sql 文件导入mysql -uroot -p source /path/to/hotel_db.sql;导入结束以后用初始账号测试登录基本就把数据库初始化的环节跑通了。数据库里通常会有一批演示数据比如默认管理员账号和预置的房间记录这些数据在需求文档里一般也有说明。想加深理解的话可以把登录密码从明文改成 MD5 加盐存储顺势落实需求文档里“登录安全性”这个条款。5.2 高频报错与排查对照表部署 SSM 项目的报错几乎集中在几类。把这个对照表存进自己的排错文档比每次上网重新搜要省时间现象根因排查方向Invalid bound statement (not found)Mapper 接口与 XML 映射文件没有正确绑定检查 XML 的 namespace 是否等于接口全限定名检查 mapper-locations 路径Failed to obtain JDBC Connection数据库连接参数错误或 MySQL 未启动mysql -uroot -p 登录测试检查 url 的端口、库名与 serverTimezone页面 CSS/JS 全挂静态资源被 SpringMVC 拦截在 springmvc-config.xml 配 mvc:resources路径指向 /static/中文乱码请求或响应的编码过滤器缺失配置 CharacterEncodingFilterforceEncodingtrue其中 Invalid bound statement 是最容易反复出现的命名空间写错、SQL 的 id 与 Mapper 方法名不一致、mapperLocations 路径不匹配三个坑任意踩到都会抛这个异常。从 MyBatis 源码的 MappedStatement 解析流程来看XML 里每个 statement 的 id 都会注册到 Configuration 对象Mapper 接口被动态代理调用时按方法名精确查找查不到就直接抛异常所以看到这类日志最高优先级就是核对命名空间和方法 id。5.3 三分钟验收确认系统真的可用给出一套三分钟验收动作不需要等页面全部点完启动成功后访问登录页输入默认管理员账号能进入后台说明登录链路和数据查询链路是通的然后浏览房间管理页面房间列表展示出初始数据说明 MyBatis 结果映射成功再做一个带条件的查询比如按“套房”筛选能过滤出对应房型说明动态 SQL 正常工作。三个动作都通过核心功能就已经落地。订单流程用两个账号分别操作一遍确认状态流转的联动逻辑符合预期这套基于 SSM 框架的酒店管理系统就算是真正可以交付的状态了。本文还有配套的精品资源点击获取