Java酒店预订系统源码拆解：JDBC事务与MVC实战

简介：一份基于 Java 的酒店预订系统实战项目，面向希望掌握 Web 开发全流程的初学者与进阶开发者，展示从用户查询、预订酒店到订单处理的核心业务闭环。项目覆盖 MVC 分层设计、Servlet/JSP 前后端交互、JDBC 数据库操作，以及 Spring、MyBatis 等主流框架的整合方式，同时涉及用户认证、权限控制、异常处理和单元测试等工程化实践，便于理解企业级 Web 应用的常见组织方式。压缩包共 41 个文件，以 34 个 java 源码文件为主，辅以 properties 配置、xml 工程配置和 md 说明文档，整体仅 83KB；目录结构精简，可快速定位业务模块、配置项与说明文档。已有 74 人学习下载，适合作为课程设计、毕业设计或面试前的练手素材。通过阅读源码，可直观理解酒店信息、房间状态、订单等表的设计思路，掌握控制层、业务层与数据层之间如何协作完成一次真实预订流程；项目中包含的数据库交互和权限控制代码，尤其适合对照实战场景提升 Java Web 开发与排错能力。

1. Java酒店预订系统：为什么我建议你从这套“老技术”源码拆起

如果你点进这篇文章，大概率是搜“java酒店预订系统源码”想找个能跑、能学、能交作业的项目。先说结论：这份java+酒店预订系统.zip既不是花哨的微服务架构，也不是炫技的前后端分离工程，它就是一套用 Servlet + JSP + JDBC 写出来的经典 Java Web 单体应用。放在今天看，技术栈确实“老”，但正是这份“老”让它成了学 Java Web 的黄金解剖样本——没有框架帮你藏起细节，从 HTTP 请求到 SQL 执行，每一行代码都在明面上。

这套系统适合三类人：刚学完 Java SE、想搞懂 Web 项目到底怎么串起来的初学者；准备面试、需要拿一个完整业务逻辑去讲 MVC 和数据库设计的求职者；以及想快速改造做课程设计或毕业设计的学生。它能解决的问题很具体：酒店信息的增删改查、房间状态管理、用户注册登录、在线下单预订，以及订单状态的前后端联动。你下载后能跑起来，改得动，说得清，这就够了。

2. 项目跑起来：从源码包到 Tomcat 部署全流程

拿到 zip 包，先别急着写代码。老手拿到任何源码的第一件事是把它跑起来，让代码和自己建立“信任感”。我在第一次拆这套系统时，从解压到浏览器看到登录页只用了不到十分钟，中间踩了几个经典的坑，下面的流程照做基本不会翻车。

2.1 解压与目录结构：先搞清楚包里有什么

解压后你会看到典型的 Eclipse/IDEA 项目结构。记住，这不是 Maven 工程，别直接用mvn clean package去构建，老老实实按 Web 项目来导入。

java-hotel-system/ ├── src/ │ ├── com.hotel.entity # 实体类：User, Hotel, Room, Order │ ├── com.hotel.dao # 数据访问对象：含 JDBC 操作 │ ├── com.hotel.service # 业务层：预订逻辑、登录校验 │ ├── com.hotel.servlet # Controller：接收前端请求 │ └── com.hotel.util # 工具类：DBUtil, DateUtil ├── web/ │ ├── WEB-INF/ │ │ ├── web.xml # Servlet 映射与过滤器配置 │ │ └── lib/ # 依赖 jar 包：mysql-connector-java 等 │ ├── css/ js/ # 前端静态资源 │ ├── login.jsp index.jsp # 视图页面 │ └── ... └── sql/ └── hotel.sql # 建库建表脚本

有同学会问：为什么实体类是com.hotel.entity而不是com.hotel.model？这纯粹是早期 Java 项目的习惯，实体对象代表数据库表的一行记录，叫 entity 还是 model 都可以，重点在于职责划分清楚。另外注意lib/目录，里面是手动导入的 jar 包，源码包不依赖 Maven 拉取，这意味着你只需要配好 JDK 和 Tomcat 就能启动，入门的门槛其实更低。

2.2 数据库初始化：先建库再谈其他

这套系统用的是 MySQL，源码的sql/hotel.sql已经建好了表结构和初始数据。我一般习惯用命令行执行，比 Navicat 更能看到报错细节：

mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS hotel_db DEFAULT CHARSET utf8mb4;" mysql -u root -p hotel_db < sql/hotel.sql

第一条命令创建hotel_db数据库，指定utf8mb4字符集是为了让中文房间描述不乱码。第二条命令把建表和初始数据脚本跑进去。如果你的环境没有免密登录，把-p后面加上密码，比如-p123456。执行完用SHOW TABLES;检查一下是否生成了预期中的表。

这里有个容易忽视的点：脚本里如果有DROP TABLE IF EXISTS语句，执行前想清楚，它会把已有的旧表直接干掉。我在做二次开发时曾不小心把线上环境的同名库给清了，从那以后我每次执行 SQL 脚本前都会用grep -E "DROP|DELETE"看一眼。

代码后逻辑说明：这两条命令完成的是“基础设施准备”。第一条命令中的DEFAULT CHARSET utf8mb4很关键，MySQL 默认的latin1存储中文会乱码，后面你再怎么改 Java 代码都无济于事。第二条命令将包含多条 SQL 语句的脚本文件导入指定数据库。参数-e表示执行命令后退出，适合写脚本自动化部署。

2.3 配置 JDBC 连接参数：数据源四件套

数据库建好了，接下来让 Java 代码知道怎么连。打开com.hotel.util.DBUtil，你会看到类似下面的代码：

private static final String DRIVER = "com.mysql.jdbc.Driver"; private static final String URL = "jdbc:mysql://localhost:3306/hotel_db?useSSL=false&characterEncoding=utf8"; private static final String USERNAME = "root"; private static final String PASSWORD = "123456"; static { try { Class.forName(DRIVER); } catch (ClassNotFoundException e) { e.printStackTrace(); } }

注意useSSL=false这个参数。MySQL 8.x 默认开启 SSL，但我们的本地开发环境根本不需要加密，不关掉就会连带着警告刷屏，换成高版本驱动（如mysql-connector-java-8.0.x）、即使DRIVER的类名也同步换成com.mysql.cj.jdbc.Driver。

代码后的参数说明：URL里的3306是 MySQL 默认端口，hotel_db是我们在第一步创建的库名。characterEncoding=utf8确保 Java 写入数据库的中文不会被转成乱码。Class.forName(DRIVER)是在加载驱动类，这段代码是 JDBC 4.0 之前的老写法，新版驱动支持 SPI 自动加载，写不写都行，但源码既然这么写，就保留原汁原味。

2.4 部署到 Tomcat：用 IntelliJ IDEA 还是 Eclipse

源码里带了.project和.classpath文件，说明原生是在 Eclipse 里开发的。但这年头新手用 IDEA 更多，两种方式我都试过。

如果是 IDEA：File -> New -> Project from Existing Sources，选中源码目录，IDE 会自动识别 Web 模块，配好 Tomcat Server 后直接Run。注意 IDEA 默认不编译WEB-INF/lib下的 jar 包依赖，如果启动报ClassNotFoundException: com.mysql.jdbc.Driver，去Project Structure -> Artifacts里把lib目录加入打包范围。

如果是 Eclipse：File -> Import -> General -> Existing Projects into Workspace，然后右键项目Run As -> Run on Server。Eclipse 对传统 javaweb 项目的兼容性好得多，几乎不用额外配置。

部署过程中最常见的报错是 404 或者请求路径对不上。这是 web.xml 里 Servlet 映射路径写的是/login，但你访问的是http://localhost:8080/hotel/login导致。项目名（context path）默认就是部署包名，如果你改了 war 包的名字，访问路径也要跟着改，这个坑我们放到第五章统一排查。

3. 拆解一次预订流程：MVC 三层到底在处理什么

跑起来后，很多人会急于改代码，但我觉得先把系统的“一次典型请求”完整串一遍更重要。以“用户查询酒店 -> 查看房间 -> 提交订单”这个链路为例，看看数据是怎么从前端到数据库再回到前端的结果。

3.1 请求入口：web.xml 里的映射规则与 Servlet 路由

这套系统的入口是web.xml。我们看其中一段配置：

<servlet> <servlet-name>HotelServlet</servlet-name> <servlet-class>com.hotel.servlet.HotelServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>HotelServlet</servlet-name> <url-pattern>/hotel</url-pattern> </servlet-mapping>

url-pattern用/hotel而不是*.do，说明这个系统用的是“路径映射”而非“后缀映射”。浏览器里输入http://localhost:8080/hotel_project/hotel?action=queryList，Tomcat 会把请求交给HotelServlet。问号后面的action=queryList是前端传过来的指令参数，Servlet 层根据这个参数决定调用哪个业务方法——这就是最原始的“前端控制器”思想，很多框架的路由本质是对它的一层封装。

如果你以后看 Spring MVC，会发现 DispatcherServlet 干的事和这里的HotelServlet如出一辙，只是把 switch-case 变成了更灵活的注解映射。所以别小看这套老代码，理解了它，学框架会顺畅很多。

3.2 三层的边界：Servlet 只做转发，Service 只做业务

严格按 MVC 分层，这套系统有一个很值得学习的规矩：Servlet 里不写 SQL，DAO 里不写业务判断。截取HotelServlet的一段关键代码：

String action = request.getParameter("action"); if ("queryList".equals(action)) { List<Hotel> hotelList = hotelService.queryAllHotels(); request.setAttribute("hotelList", hotelList); request.getRequestDispatcher("/hotelList.jsp").forward(request, response); } else if ("bookRoom".equals(action)) { int hotelId = Integer.parseInt(request.getParameter("hotelId")); int roomTypeId = Integer.parseInt(request.getParameter("roomTypeId")); int userId = Integer.parseInt(request.getSession().getAttribute("userId").toString()); boolean success = orderService.createOrder(userId, hotelId, roomTypeId); if (success) { response.sendRedirect("orderSuccess.jsp"); } else { request.setAttribute("errorMsg", "该房间已满，请更换房型"); request.getRequestDispatcher("/bookFail.jsp").forward(request, response); } }

这段代码里有三个值得复用的细节。第一，Servlet 的职责是取参数、调服务、做跳转，绝不触碰Connection或PreparedStatement。第二，sendRedirect和forward的区别：重定向改 URL、request 里的属性会丢；转发不改 URL、属性能带到 JSP。上面成功用重定向、失败用转发，是为了防止刷新页面时订单重复提交——这个坑后面还会展开。第三，从 session 里拿userId时要判空，否则用户没登录直接发起bookRoom，这里Integer.parseInt(null)会直接抛NumberFormatException。

再往下走，业务层OrderService.createOrder()里会先查房间剩余数量，再扣库存、插入订单。这套代码里可能是同步的synchronized或者在 SQL 里加where remain > 0做防超卖，具体逻辑后面第四章讲订单表结构时说。

3.3 前端 JSP 里的 Java 片段：老项目的黑匣子所在

JSP 页面里到处都是<% %>和<%= %>片段，这是早期 Java Web 的典型特征。比如酒店列表页：

<% List<Hotel> list = (List<Hotel>) request.getAttribute("hotelList"); if (list != null) { for (Hotel h : list) { %> <div class="hotel-card"> <h3><%= h.getName() %></h3> <p>星级：<%= h.getStarLevel() %> 星</p> <a href="hotel?action=detail&hotelId=<%= h.getId() %>">查看房型</a> </div> <% } } %>

这种写法有个大问题：JSP 变成了视图和业务的混合物，而request.getAttribute拿到的对象如果类型不对，强转时直接抛ClassCastException。我见到的很多初学者在后端改了属性名没同步前端，页面上就是 500 或者空白，排查半天才发现是这里写错了。

但反过来看，这种“小脚本”也有好处——你不需要理解自定义标签或 EL 表达式就能看懂页面逻辑。老系统的黑匣子往往不黑，只是没人静下心来逐行读。前端交互层面，这套系统用了 jQuery，页面底部会有$.getJSON或$.ajax的异步请求，下次我们讲“房型动态加载”时再细看。

4. 数据库设计与订单状态流转：业务系统的骨架

这一章是绝大多数人忽略但面试官最爱问的地方。酒店预订系统的核心不在前端页面，而在数据库表怎么设计、订单状态怎么流转。

4.1 核心表结构与关系设计

sql/hotel.sql里一般包含这五张表：

注意t_room_status这张表，它是这套系统的精髓。酒店订房和其他电商不一样：你订的是“某个日期的某间房”，不是“某个酒店随便住”。所以库存一定要按“日期 + 房型”维度来记录，remain_count表示该房型在特定日期的剩余可订数。

t_order.status通常用整数或字符串标识状态机，常见取值：0 已取消、1 待入住、2 已入住、3 已完成。有的实现里还有 4 已过期，用来处理“订了没住”的情况。

代码后的说明：在这个表结构中，t_room_status的联合唯一索引可以建在(room_type_id, date)上，防止同一天同一房型被插入多行初始数据。剩下数量扣到 0 时就不能再预定了，这就是“防超卖”的数据库兜底方案。

4.2 预订订单：事务与并发的那点事

OrderService里的createOrder方法大概率是这个项目里最复杂的业务代码了。伪代码理一下：

@Transactional(readOnly = false, rollbackFor = Exception.class) public boolean createOrder(int userId, int hotelId, int roomTypeId, String date) { // 1. 用户是否登录（调用方保证） // 2. 查房型当日剩余: SELECT remain_count FROM t_room_status WHERE room_type_id=? AND date=? // 3. 剩余为 0 直接返回失败 // 4. 扣减库存: UPDATE t_room_status SET remain_count = remain_count - 1 WHERE room_type_id=? AND date=? AND remain_count > 0 // 5. 受影响的记录行数为 1 说明扣减成功，否则说明被别人抢了，回滚 // 6. 插入订单记录，状态置为 1（待入住） // 7. 返回 true }

核心在第 4 步的 SQL。它不是先查后改，而是把“查”和“改”合并成一条带条件的UPDATE：

UPDATE t_room_status SET remain_count = remain_count - 1 WHERE room_type_id = ? AND date = ? AND remain_count > 0;

注意看，条件里带了remain_count > 0。这是一个非常实用的技巧：即使两个并发请求同时读到剩余数为 1，这条 UPDATE 在数据库层的行锁保证下，只有一个能执行成功，另一个的影响行数为 0，从而避免超卖。如果你的项目里没有加这个条件，那它大概率是先用 SELECT 查，再 UPDATE，并发下库存必错。

我见过很多学生把这套单纯当“增删改查”，但实际上它的订单片段才是整个系统的利润所在。面试时如果能主动说出“原子扣库存”这个细节，比背十篇八股文都管用。

4.3 状态流转与用户操作映射

酒店预订的流程一般这样：用户下单选“待入住”，到店后管理员后台点击“办理入住”变“已入住”，退房后变“已完成”。用户可以在“待入住”状态下点击“取消”，订单变“已取消”。

这套系统的状态流转不一定做成独立的表或配置类，判断逻辑经常散落在 Servlet 和 Service 里。常见的粗心问题是：取消订单时只改了订单状态，没有把t_room_status.remain_count加回去，导致库存越攒越少，最终无房可订。如果你在自己的项目里遇到“为什么写着写着没房了”，十有八九是少了这一步——这是一个被我翻了车的同类项目反复验证过的结论。

实操时，取消订单和将对应日期库存变更放在同一个事务里，只改状态是错的。状态设计上，我习惯在代码里把状态存为static final int常量并集中管理，而不是在 JSP 里散落一堆裸数字，这样后续改成枚举时不会遗漏。

5. 常见问题排查：部署、数据库、编码与并发避坑记录

拆这套项目时我踩过不少不该踩的坑，也帮别人排查过大量同类问题。这一章把你大概率会遇到的问题提前摆出来，遇到时照着索引去查，少走弯路。

5.1 启动 404：先查 context path 再查 web.xml

现象：Tomcat 成功启动，但访问http://localhost:8080/login.jsp报 404，而访问http://localhost:8080/hotel_project/login.jsp却正常。

原因：Tomcat 部署时的应用名（context path）默认是 war 包名，与源码里的项目名不一致。访问根路径时没有映射到你的应用。

解决：直接在访问地址里加上项目路径；或者把部署包重命名为ROOT.war（这样能直接通过根域名访问）。在 IDEA 里可以在Run Configuration -> Deployment里修改Application context，更推荐改成/。

5.2 页面中文变问号：三层编码缺一不可

现象：页面显示“？？”，数据库里存的是问号，或者反过来页面正常但数据库字段乱码。

原因：编码链有三环——浏览器发请求的编码、Tomcat 内部处理的编码、MySQL 存储的编码。任何一环断了都会出乱码。老项目没有 Spring 的CharacterEncodingFilter，需要自己注册，或者每行代码手动 set。

解决：最省事的办法是在 web.xml 里配置编码过滤器，或者确认每个 Servlet 里都调用了request.setCharacterEncoding("UTF-8")。同时确认 MySQL 连接 URL 带characterEncoding=utf8。三处全对齐才能根治，缺一处都是玄学。

5.3 报错ClassNotFoundException: com.mysql.jdbc.Driver

现象：启动项目后，访问任何和数据库有关的页面直接 500，控制台打印找不到驱动类。这是一个超级常见但解决起来却很简单的问题。

原因：jar 包没有编译到WEB-INF/classes下。在 IDEA 中，放在WEB-INF/lib下的 jar 包需要手动把它标记为 Library，并且在 Artifacts 输出的WEB-INF/lib中包含它。Eclipse 里则是 Build Path 里没有添加这个外部 jar。

解决：IDEA 用户到Project Structure -> Libraries添加，再到Artifacts -> Output Layout确认 jar 被拉到WEB-INF/lib下。Eclipse 用户右键项目Build Path -> Configure Build Path -> Add External JARs。如果还不行，直接把 jar 复制到 Tomcat 的 lib 目录下——这个办法最暴力也最有效。

5.4 刷新页面订单重复提交：PRG 模式的作用

现象：用户提交订单后，浏览器地址栏还是/hotel?action=bookRoom，按 F5 刷新，订单插入了两条。

原因：表单提交是 POST 方式，提交后当前页面仍是 POST 的响应页，刷新时浏览器会重复发送上次的请求，导致订单重复创建。这是经典问题，不是这套系统独有。

解决：提交成功后的处理，绝不能用forward跳转，用sendRedirect让浏览器跳转到一个新的 GET 请求地址，比如订单成功页。这个过程叫 PRG（Post/Redirect/Get）模式。前面我们在 3.2 里提到成功用重定向，就是为这个。

5.5 并发下库存变负：检查 SQL 是否带条件

现象：多个用户同时订最后 1 间房，库里出现remain_count = -1的脏数据。

原因：代码里先 SELECT 剩余数，判断大于 0，再 UPDATE 减一。在高并发下两个请求同时通过判断，随后各自执行更新，库存被扣到负。

解决：如果你发现源码中 UPDATE 语句不带WHERE remain_count > 0，建议把它补上。并且UPDATE之后判断rows == 0就回滚。这是成本最低、效果最好的防超卖方案，改一行 SQL 就能解决。如果你的业务量大了，再用 Redis 分布式锁或乐观锁，但学生项目和课程设计完全不需要。

以上五条是我和这套源码以及类似项目打交道的血泪经验，前三条属于环境问题，网上也有各种答案，但不如这一份来得齐全；后两条是业务逻辑问题，面试时能说出这两点，会让人觉得你真的跑通了项目而不是只看了文档。

6. 进阶方向：从 JDBC 到 Spring 与 MyBatis 的迁移路径

看到这里，如果你已经能熟练说出项目里每个 Servlet 对应哪个 URL、每个 DAO 方法对应哪条 SQL，那么这套系统的使命已经完成了一半。剩下的一半就是把它往现代框架演进，去理解和体验“框架到底帮我们做了什么”。

6.1 先看一份映射需求：把 JDBC 代码替换为 MyBatis

以OrderDAO为例，原来我们用PreparedStatement拼INSERT INTO t_order VALUES(...)，MyBatis 的做法是把 SQL 独立到 XML 或注解中。

<insert id="insertOrder" parameterType="com.hotel.entity.Order"> INSERT INTO t_order(user_id, hotel_id, room_type_id, check_in_date, check_out_date, status) VALUES (#{userId}, #{hotelId}, #{roomTypeId}, #{checkInDate}, #{checkOutDate}, #{status}) </insert>

代码后的说明：#{userId}是预编译参数，等价于原来PreparedStatement的?占位符，但更语义化。parameterType传实体类，MyBatis 用反射自动映射到表字段。你直观体会一下：原来 DAO 里十几行样板代码，现在只剩五六行，这就是框架带来的效率提升。

如果你有兴趣，可以在这套系统上做一个最小迁移：把t_user的insert和selectByUsername改成 MyBatis 版，其余先不动。一个表一个表地迁移，比重新写一套 Spring Boot + Vue 更有对比冲击力，也能让你切实理解 ORM 和 JDBC 的边界在哪里。Hibernate 的迁移同理，重点是要理解它为什么有“一级缓存”和“懒加载”，以及它对事务边界的管理策略。

6.2 事务从手动提交到 Spring 接管：改一处，稳全局

JDBC 时代的手动事务长这样：

conn.setAutoCommit(false); try { // 扣库存 + 插入订单 conn.commit(); } catch (Exception e) { conn.rollback(); }

如果用 Spring，只需要在OrderService上声明：

@Service public class OrderServiceImpl implements OrderService { @Transactional(rollbackFor = Exception.class) public boolean createOrder(OrderDTO dto) { // 扣库存 roomTypeDao.deductStock(dto.getRoomTypeId(), dto.getDate()); // 插入订单 orderDao.insert(dto); return true; } }

代码后的说明：@Transactional让 Spring 的 AOP 拦截方法调用，自动开启和提交事务，异常时自动回滚。你不用再手动 setAutoCommit，Spring 管理连接的方式也更优雅。原来Class.forName(driver)和getConnection全会被 DataSource 取代，你写在DBUtil里的那些代码就只作为理解底层原理的教材了。

6.3 把前端 JSP 替换为前后端分离接口时的注意点

很多刚学完这套系统的同学会继续学 Vue，然后想把它改造成前后端分离，这一步是把后端 Servlet 改造成简单的 JSON 接口。一个注意点：原来的 Servlet 返回RequestDispatcher.forward(...)到 JSP 页面，现在需要改写response.setContentType("application/json;charset=UTF-8")并直接输出 JSON 字符串。常见做法是不再用 JSP，而是用 FastJSON 或 Jackson 将hotelList序列化后写进PrintWriter。

这个改造过程会暴露一个问题：老代码里的 Servlet 职责过重。很多方法里既做参数接收又做 BUG 提示，当时的价值观是“能跑就行”，但你拆分接口时不能照抄，先按“参数校验 -> 调用 Service -> 返回统一 Result”的思路重写一遍接口逻辑，效率反而更高。通过这次改造，你会顺便弄懂 CORS 跨域是个什么东西，也是在为 Spring Boot 的学习扫平障碍。

6.4 一个收尾的小习惯：自己造订单号

整套系统最终能跑通后，我强烈建议你做一个很小的功能增强：把订单编号从自增 id 改成自定义生成的字符串编号，比如HJ202406151430001这种格式。去写一个OrderNoGenerator工具类，研究一下怎么保证并发下的唯一性。这个功能非常小，但它是从“练习项目”迈向“真实系统”的重要一步。从那以后我每次做完一套学习项目，都强制自己挑一个“看起来很简单但实际有坑”的模块去增强，走完一遍才敢说自己彻底读懂了这套代码。

希望这篇拆解笔记能帮你把java+酒店预订系统.zip里的每一行代码都吃透，也祝你顺利找到下一个更适合自己的实战项目。

本文还有配套的精品资源，点击获取