企业官网建设流程全解析

简介：月亮湾酒店管理系统是一套使用 Java 语言开发的完整酒店业务管理源码，数据库基于 SQL Server 2008r2 以上版本，适合计算机相关专业学生、Java 入门开发者以及需要课程设计或毕业设计参考的人群。资源共 350 个文件，压缩包约 9.74MB，包含 56 个 Java 源文件、60 个 class 编译文件、176 张界面功能演示 gif 图片、sql 数据库脚本及 mdf/ldf 数据库物理文件，另有概要设计、数据库设计、需求说明、详细设计、用户手册等 5 份配套文档。功能层面覆盖散客登记/退房、团体入住、预订管理、账务查询等核心模块，配合演示动图可直观了解系统操作流程。目前已有 101 人学习下载，对于需要快速掌握 Java Swing 桌面应用开发、数据库表结构设计与业务流程实现的学习者而言，是一份可运行、可修改、兼具文档支撑的参考范例。

1. 月亮湾酒店管理系统：为什么值得你亲手跑一遍

硬盘里躺着一个“亲测 java 开发的月亮湾酒店管理系统源码（含 SQL Server 数据库）.rar”，解压之前既希望它配得上“亲测”二字，又担心自己手上的环境根本跑不起来。这类压缩包的典型组成是一套 Java 课设工程加一份 .sql 数据库脚本，功能上覆盖员工登录、客房管理、预订、入住登记、退房结账这几个酒店管理系统的标配流程，界面通常是 Swing 或 JSP，数据层清一色 JDBC。真正卡住新手的往往不是 Java 代码本身，而是 SQL Server 环境、数据库脚本和 JDBC 连接参数这一串问题。这篇文章从源码结构、环境搭建、核心业务实现到高频报错，告诉你这种课设系统怎么跑通、怎么看懂、怎么改，给准备交作业的在校生和刚学完 JDBC 想练手的人一条可靠路径。

2. 先把源码结构看穿：分层、JDBC 与 SQL Server 的选型逻辑

2.1 拿到压缩包先做三件事：解压、看包名、找 SQL 脚本

别急着双击运行，先把压缩包解压到一个不含中文和空格的目录，比如D:\moonbay-hotel。解压之后按照下面三步走，能省掉后面一大半的翻车时间。

第一步，打开工程目录看一眼整体结构，正常的 Java 课设工程一般长这样：

D:\moonbay-hotel ├─ src │ ├─ com │ │ └─ moonbay │ │ ├─ dao # 数据库访问层 │ │ ├─ model # 实体类 │ │ ├─ view # 界面层（Swing / JSP） │ │ ├─ util # 数据库连接工具类 │ │ └─ Main.java # 入口 ├─ lib # 依赖 jar，通常有 sqljdbc 驱动 ├─ sql │ └─ moonbay_hotel.sql └─ db.properties # 数据库连接配置

src目录是 Java 源码，lib目录装着依赖的 JDBC 驱动 jar，sql目录里的.sql脚本是整个系统的“数据库灵魂”，db.properties是数据库连接配置，后面的运行步骤全都要改这个文件。

第二步，用文本编辑器打开任意一个.java文件，看第一行的package声明。如果包名里有daomodelview这样的分层，说明这个系统是标准的 JDBC 三层写法；如果全是framepanel之类的包名，那就是界面和逻辑混在一起的简化版。前者更适合学习，后者改起来更费劲。

第三步，打开sql目录下的脚本，确认里面有没有创建数据库、建表、插入初始数据的语句。有些压缩包只给表结构不给数据，登录时就会发现账号密码根本不存在，这是后文要专门处理的坑。

做完这三件事，你对这个压缩包的“长相”就有了底。接下来要回答一个更关键的问题：为什么这类酒店管理系统普遍用 JDBC 直连 SQL Server，而不是 MyBatis 加 MySQL。

2.2 为什么课设系统爱用 JDBC + SQL Server，而不是 MyBatis/MySQL

很多人在拿到这类源码时都会有个疑问：现在企业开发都用 Spring Boot 加 MyBatis，为什么课设还停留在 JDBC 手写Connection和PreparedStatement？

原因很现实：第一，很多高校的数据库课程默认使用 SQL Server，机房机器上装的就是它，教学和考试都围绕 SQL Server 展开；第二，课设考察的是“你能不能讲清楚数据库原理”，JDBC 直连能让你把每一步都摊开看，连接怎么建、语句怎么执行、结果集怎么遍历，而 MyBatis 把这些细节封装掉了；第三，JDBC 项目依赖少，一个驱动 jar 就能跑，不需要 Maven 拉一堆依赖，离线环境也能运行。

SQL Server 和 MySQL 之间的语法差异也是这类项目的一个隐藏考点。同样是自增主键，MySQL 写AUTO_INCREMENT，SQL Server 写IDENTITY(1,1)；同样是分页，MySQL 用LIMIT，SQL Server 用OFFSET ... FETCH；同样是字符串类型，SQL Server 有varchar和nvarchar之分，存中文时选错类型就会出现乱码。这些差异经常是“明明代码对了，却在 SQL Server 上翻车”的根源。

如果你手里这套月亮湾系统用的是 SQL Server，那么在理解代码时就要按右边这一列来想问题。比如插入一条订单记录，主键生成方式是IDENTITY，就不需要手动给主键赋值，写 SQL 时得把这一点避开，否则就会碰到后面要讲的“主键冲突”。

2.3 读懂数据表关系：employee、room、orders 三张核心表

酒店管理系统的数据模型无论怎么设计，都绕不开员工、客房、订单这三张核心表。以常见的月亮湾系统脚本为例，三张表的简化结构如下：

-- 员工表 CREATE TABLE employee ( emp_id INT IDENTITY(1,1) PRIMARY KEY, emp_no VARCHAR(20) NOT NULL UNIQUE, -- 登录工号 emp_name NVARCHAR(20) NOT NULL, -- 员工姓名，用 NVARCHAR 避免中文乱码 emp_pwd VARCHAR(64) NOT NULL, -- 登录密码，课设常见明文或 MD5 role VARCHAR(10) DEFAULT '前台' -- 角色：经理 / 前台 / 保洁 ); -- 客房表 CREATE TABLE room ( room_id INT IDENTITY(1,1) PRIMARY KEY, room_no VARCHAR(10) NOT NULL UNIQUE, -- 房号，比如 301 room_type NVARCHAR(20) NOT NULL, -- 单人间 / 双人间 / 套房 price DECIMAL(10,2) NOT NULL, -- 门市价，用 DECIMAL 不用 MONEY status VARCHAR(10) DEFAULT '空闲', -- 空闲 / 已订 / 入住 / 脏房 floor_no INT -- 楼层 ); -- 订单表 CREATE TABLE orders ( order_id INT IDENTITY(1,1) PRIMARY KEY, order_no VARCHAR(30) NOT NULL UNIQUE, -- 订单号 emp_id INT NOT NULL REFERENCES employee(emp_id), room_id INT NOT NULL REFERENCES room(room_id), customer_name NVARCHAR(20) NOT NULL, customer_idcard VARCHAR(18), -- 身份证号固定 18 位 customer_phone VARCHAR(11), check_in_date DATETIME NOT NULL, check_out_date DATETIME, total_amount DECIMAL(10,2), status VARCHAR(10) DEFAULT '入住' -- 入住 / 已退房 );

这里有两个值得注意的设计细节。

第一个是room.status字段。房间状态是这个系统的“状态机”核心：空闲、已订、入住、脏房四种状态互相切换。入住登记时要把空闲改成入住，退房结账后要改成脏房，保洁清理后再改回空闲。代码里所有关于房间的业务逻辑，本质上都是在改这个字段，所以这个字段的类型和取值范围必须稳定。

第二个是金额字段统一用DECIMAL(10,2)而不是MONEY。SQL Server 的MONEY类型虽然名字看起来专为货币设计，但它在运算时存在舍入精度问题，累计房费、折扣计算时容易差几分钱。DECIMAL(10,2)是课设和实际项目都更稳妥的选择。

看懂这三张表的关系，后面再去看 DAO 层的增删改查，就是一一对应的事：查员工表做登录、改房间表做开房、插入订单表做登记。如果结构不是这三张表的名字，也不用慌，万变不离其宗，认准“员工、房间、订单”这个三元组就能快速定位功能模块。

3. 在本地跑通月亮湾系统：JDK、SQL Server 2019、SSMS 的最小配置

3.1 环境版本怎么定：JDK 与 mssql-jdbc 的兼容矩阵

环境版本不匹配是这类源码跑不起来的第一大原因。月亮湾系统如果是传统 JDBC 课设，通常运行的 JDK 是 8 或 11，项目里的lib目录会放一个mssql-jdbc驱动 jar。可当你自己手头只有 JDK 17 时，老版本的驱动可能直接抛异常，比如UnsupportedClassVersionError。

驱动版本和 JDK 的常见搭配可以按下面这张表来选：

判断项目里 jar 版本的办法很简单：在lib目录下找一个名字类似mssql-jdbc-9.4.1.jre8.jar的文件，jre8就是给 JDK 8 用的；如果是mssql-jdbc-11.2.0.jre17.jar，那就配 JDK 17。如果没有lib目录，需要自己去装一个驱动，这时建议直接选11.2.0.jre11.jar或10.2.0.jre8.jar，兼容性最好。

SQL Server 版本方面，SQL Server 2016、2017、2019、2022 都能跑这不是它的问题，更老的项目如果建库脚本里用了Chinese_PRC_CI_AS排序规则，这些新版本依然支持。我一般以 SQL Server 2019 作为推荐目标，因为安装教程多、网上踩坑案例全，出了问题容易搜到答案。

3.2 SQL Server 安装后要立刻改的三个设置：混合登录、TCP/IP、sa 密码

SQL Server 刚装完默认状态并不能直接给 Java 程序用，有三个设置必须改，否则后面的 JDBC 连接基本必失败。

第一步，启用“SQL Server 和 Windows 身份验证模式”。用 SSMS（SQL Server Management Studio）以 Windows 身份连接到实例，右键实例名，选择“属性”，在“安全性”页签下选中“SQL Server 和 Windows 身份验证模式”，确定后重启 SQL Server 服务。这一步没做，后面用sa和密码登录时就会报 18456 错误。

第二步，在 SQL Server 配置管理器中启用 TCP/IP 协议。打开“SQL Server 配置管理器”，展开“SQL Server 网络配置”，点击实例对应的“协议”，右键“TCP/IP”选择“启用”。双击“TCP/IP”，在“IP 地址”页签最下面找到“IPAll”，把“TCP 端口”改为 1433。这是 JDBC 连接时默认用的端口，不启用协议的话程序会一直卡在连接超时。

第三步，给sa账号设置一个明确密码。用 Windows 身份登录 SSMS，在安全性节点下找到sa，右键属性，设置密码，并在“状态”页签里把“登录”改为“启用”。注意 SQL Server 的密码策略默认要求强密码，如果只是本机测试，可以先把“强制密码策略”勾掉，降低调试复杂度。

这三步做完，重启一次 SQL Server 服务，就为后面的 JDBC 连接铺好了路。很多新手在这里漏掉了其中某一步，导致后续所有代码都像是“连不上数据库”，其实问题根本不在代码。

3.3 执行建库脚本并修改 db.properties：让程序认你的数据库

环境准备好之后，先把数据库脚本执行进去。如果sql目录下的脚本里已经包含了CREATE DATABASE moonbay，直接用 sqlcmd 一条命令执行：

sqlcmd -S localhost -U sa -P "你的密码" -C -i D:\moonbay-hotel\sql\moonbay_hotel.sql

参数说明：-S localhost指定本机实例，-U sa和-P指定登录账号密码，-C表示信任服务器证书，解决自签名证书导致的连接失败问题，-i指定要执行的 SQL 脚本路径。如果 sqlcmd 不在系统环境变量里，可以用 SSMS 打开脚本文件，选中全部语句后直接执行，效果相同。

执行完后在 SSMS 里刷新数据库列表，看到moonbay数据库就说明脚本成功跑了。接下来打开工程根目录的db.properties，把连接信息改成你自己的环境：

jdbc.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver jdbc.url=jdbc:sqlserver://localhost:1433;databaseName=moonbay;encrypt=false;trustServerCertificate=true jdbc.username=sa jdbc.password=你的密码

这段配置里的encrypt=false和trustServerCertificate=true是重点。新版本的 mssql-jdbc 驱动默认开启了 SSL 加密连接，而本地 SQL Server 通常使用自签名证书，如果不在 URL 里关闭加密，连接时直接报“无法通过 SSL 加密建立安全连接”。加上这两个参数是最省事的做法，也是这类项目最容易踩的坑。

注意databaseName=moonbay必须和脚本里创建的数据库名完全一致，包括大小写和拼写。如果你在脚本里把数据库名改成了moonbay_hotel，这里就要同步改，否则报“数据库不存在”。

3.4 编译与运行：从源码到窗口的最小命令序列

如果项目是带lib目录的传统结构，可以在命令行里直接编译运行，这样也方便你理解 Java 程序实际依赖了哪些东西。

cd D:\moonbay-hotel # 编译 src 下所有 java 文件，输出到 out 目录 javac -encoding UTF-8 -cp "lib/*" -d out src/com/moonbay/*.java src/com/moonbay/dao/*.java src/com/moonbay/model/*.java src/com/moonbay/view/*.java # 运行主类 java -cp "out;lib/*" com.moonbay.Main

-encoding UTF-8这个参数必须加，不加的话源码里的中文字符串常量在编译时会变成乱码，界面上所有的中文按钮、提示文本全部变成问号。-cp指定类路径，lib/*会匹配 lib 目录下所有依赖 jar，Windows 下多个路径用分号分隔，Linux 或 Mac 下用冒号分隔。

如果你用的是 IDEA 或 Eclipse，等价的操作为：新建项目，把src目录标记为源码根目录，把lib里的 jar 添加到项目依赖，然后在运行配置的主类里填com.moonbay.Main。运行后如果看到登录窗口正常弹出，说明整套环境已经通了。

如果编译报错说找不到某个类，先检查lib目录里是否真的有对应 jar，以及-cp的路径是否写对。这一步最常见的翻车点是 Windows 下把分号写成了冒号，导致 jar 根本没被加载，后面第 5 章还会单独展开。

4. 核心业务代码拆解：登录、开房、退房的关键实现

4.1 登录模块：PreparedStatement 防注入与密码散列

酒店管理系统的登录模块是 DAO 层最简单也最典型的代码。很多课设源码里直接写字符串拼接 SQL，这是必须改掉的问题。看看常见的登录写法：

public Employee login(String empNo, String pwd) { String sql = "SELECT emp_id, emp_no, emp_name, role FROM employee WHERE emp_no = ? AND emp_pwd = ?"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, empNo); ps.setString(2, md5(pwd)); try (ResultSet rs = ps.executeQuery()) { if (rs.next()) { Employee emp = new Employee(); emp.setEmpId(rs.getInt("emp_id")); emp.setEmpNo(rs.getString("emp_no")); emp.setEmpName(rs.getString("emp_name")); emp.setRole(rs.getString("role")); return emp; } } } catch (Exception e) { e.printStackTrace(); } return null; }

这里的要点有两个。第一是必须用PreparedStatement的?占位符，而不是把empNo直接拼进 SQL 字符串，否则输入' OR '1'='1这种内容就能绕过登录，这是最基础的 SQL 注入漏洞。第二是密码不能明文存储，常见做法是 MD5 散列后再比对。md5(pwd)是对密码做单向散列的函数，即使数据库泄露，攻击者也拿不到原始密码。

不过要注意，MD5 已经不再安全，课设里用来演示可以，真要上线得换成 BCrypt 或 PBKDF2。作为初学者，先把 MD5 从“明文存储”改成“散列存储”这一步做到位，就已经比大部分课设源码强了。

登录成功后的角色判断也在这个模块里完成。经理和前台看到的界面应该不同，经理能看报表、改房价，前台只能操作开房退房。如果源码里登录后只有一个窗口，那说明角色权限没做，这是第 6 章改造的重点之一。

4.2 开房登记：用事务和受影响行数挡住“一房两卖”

开房登记是酒店管理系统最核心的业务，也是最容易出并发问题的场景。两个前台同时给客人开 301 房间，如果没有保护，就会出现两个订单共用一间房的情况。JDBC 里的解决方式是用事务加“判断受影响行数”的双重保险：

public boolean checkIn(Order order) { String updateRoom = "UPDATE room SET status = '入住' WHERE room_no = ? AND status = '空闲'"; String insertOrder = "INSERT INTO orders(order_no, emp_id, room_id, customer_name, customer_idcard, customer_phone, check_in_date, status) VALUES (?, ?, ?, ?, ?, ?, GETDATE(), '入住')"; Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务，两条 SQL 要么都成功要么都失败 PreparedStatement ps1 = conn.prepareStatement(updateRoom); ps1.setString(1, order.getRoomNo()); int rows = ps1.executeUpdate(); if (rows == 0) { conn.rollback(); return false; // 房间不是空闲状态，说明被占用了 } PreparedStatement ps2 = conn.prepareStatement(insertOrder); // 设置订单字段... ps2.executeUpdate(); conn.commit(); return true; } catch (Exception e) { if (conn != null) conn.rollback(); e.printStackTrace(); return false; } }

核心逻辑在UPDATE room SET status = '入住' WHERE room_no = ? AND status = '空闲'这一句。SQL Server 在执行 UPDATE 时会锁住匹配到的行，而status = '空闲'条件保证了只有房间还是空闲时才允许更新。如果返回的受影响行数是 0，说明房间已经被改成其他状态，开房失败，回滚事务，不给后面插入订单的机会。

setAutoCommit(false)开启了事务，确保 UPDATE 和 INSERT 两条语句作为一个整体提交。如果第二条插入订单失败，第一句把房间改成“入住”的操作也要回滚，否则房间被占但订单不存在，变成脏数据。

新手最容易漏掉的是事务提交后的资源关闭。上面用了 try-with-resources 写法，PreparedStatement 和 ResultSet 会自动关闭，但 Connection 需要手动关。在实际课设代码里经常看到只关闭了 Statement 没关 Connection 的写法，短时间跑看不出问题，时间一长连接池耗尽，整个系统就假死了。

4.3 退房结算：decimal 精度与跨天房费计算

退房结账的核心是算钱。房费的计算方式通常是“每晚价格 × 住宿天数”，但这里有两个坑：一是跨天计算天数，二是金额类型的选择。

-- 计算住宿天数，两个日期都算头算尾 DECLARE @days INT = DATEDIFF(DAY, @check_in_date, @check_out_date); -- 如果当天入住当天退房，至少算一天 IF @days = 0 SET @days = 1; -- 房费计算，price 是 DECIMAL 类型，避免浮点误差 SELECT @total = DATEDIFF(DAY, @check_in_date, @check_out_date) * r.price FROM room r WHERE r.room_no = @room_no;

DATEDIFF(DAY, ...)统计的是两个日期之间跨越的日界线次数。比如 1 月 1 日晚上入住、1 月 2 日中午退房，DATEDIFF结果是 1，正好算一天房费；如果是 1 月 1 日入住、1 月 3 日退房，结果是 2，算两天。但当天入住当天退房的钟点房场景，DATEDIFF结果是 0，需要特殊处理成至少 1 天，否则免费住宿。

金额计算必须保证使用DECIMAL(10,2)类型的字段参与运算。如果把price字段定义成FLOAT或MONEY，那么 0.1 加 0.2 这种运算就可能出现 0.30000000000000004 的尴尬结果，打印在账单上非常难看。DECIMAL(10,2)在 SQL Server 中按十进制精确存储，不会出现二进制浮点误差。

退房时还要更新房间状态为“脏房”而不是“空闲”，这个细节决定了保洁流程能不能正常运转。SQL Server 的UPDATE语句在业务逻辑里承担了状态机的流转，退房操作本质上是同时执行“改房间状态 + 更新订单状态 + 计算金额”，这三步同样需要用事务包起来，做法和开房登记完全一致。

5. SQL Server 运行避坑：5 个高频翻车现场

5.1 现象：SQL Server JDBC 报“无法通过 SSL 加密建立安全连接”

这种报错的完整文本通常是“The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption”，新版 mssql-jdbc 驱动默认要求 SSL 加密，而本地 SQL Server 的证书是自签名的，驱动校验不通过就拒绝连接。

原因：不是你的 Java 代码有问题，也不是密码错误，纯粹是加密策略不匹配。

解决：在 JDBC URL 里追加两个参数：

jdbc:sqlserver://localhost:1433;databaseName=moonbay;encrypt=false;trustServerCertificate=true

encrypt=false表示不要求加密连接，trustServerCertificate=true表示信任服务器证书。本地开发时这两个参数直接加上，如果公司或学校网络强制要求加密，再讨论证书配置的问题。

5.2 现象：1433 端口连不上，程序一直卡在连接超时

连接超时和连接被拒是两种不同的表现。连接被拒说明端口根本不通，连接超时说明防火墙拦截或 IP 没监听。SQL Server 最常见的问题是安装后默认没有启用 TCP/IP 协议。

原因：SQL Server 仅启用了 Shared Memory 和 Named Pipes，JDBC 走不了 TCP/IP；或者 Windows 防火墙挡住了 1433 端口。

解决：打开 SQL Server 配置管理器，找到“SQL Server 网络配置”下的协议，右键“TCP/IP”选择“启用”；然后在“IP 地址”页签最下方确认“IPAll”的 TCP 端口为 1433。改完必须重启 SQL Server 服务，这个操作经常被忽略。防火墙方面，在“Windows Defender 防火墙”的入站规则里放行 1433 端口，或者临时关闭防火墙测试连通性。

5.3 现象：sa 登录失败，错误码 18456

错误 18456 的提示是“用户‘sa’登录失败”，这个错误包含了两种完全不同的原因：sa 账号被禁用，或者未启用混合认证模式。

原因：SQL Server 默认使用 Windows 身份验证模式，关闭了 SQL 账号登录途径；另一个常见原因是安装时没给 sa 设置密码或密码过期。

解决：用 Windows 身份登录 SSMS，右键实例属性，把“服务器身份验证”改成“SQL Server 和 Windows 身份验证模式”，然后在安全性节点里右键sa，启用登录并设置新密码。注意修改后要重启 SQL Server 服务，密码策略如果限制太严，可以暂时取消“强制实施密码策略”。

5.4 现象：数据库里的中文变成问号，界面也显示乱码

数据库表里插入的中文显示成???，或者 Java 界面上的中文全是乱码，这是课设项目里最闹心的一个问题。

原因：有三层可能。第一层是数据库排序规则不支持中文，默认的SQL_Latin1_General_CP1_CI_AS对中文字符支持不友好；第二层是 SQL 脚本文件本身是 ANSI 编码，包含中文字符的字面量在导入时被错误解析；第三层是 Java 源码编译时没指定UTF-8，中文常量变成了乱码。

解决：建库时显式指定中文排序规则：

CREATE DATABASE moonbay COLLATE Chinese_PRC_CI_AS;

如果库已经建好，可以修改库的排序规则，但改排序规则会影响已有索引和约束，最省事的方法是重建库。插入中文时尽量用N'中文'前缀，比如INSERT INTO room(room_name) VALUES(N'豪华套房')，告诉 SQL Server 这是 Unicode 字符串。Java 源码编译时用-encoding UTF-8参数，从源头避免乱码进入 class 文件。

5.5 现象：ClassNotFoundException：com.microsoft.sqlserver.jdbc.SQLServerDriver

启动程序直接报找不到驱动类，这个错误最直观，也最容易排查。

原因：驱动 jar 不在 classpath 里。可能是lib目录里根本没有这个 jar，也可能是项目里引用了但没加入构建路径。

解决：先确认驱动 jar 是否存在，没有的话去微软的 mssql-jdbc 发布页下载合适的版本，放进lib目录，然后在 IDE 里右键 jar“添加到库”。命令行运行的话检查java -cp是否写了lib/*。有个细节：Windows 命令行里 classpath 分隔符是分号，写成冒号会导致路径解析失败，驱动同样加载不出来。

6. 进阶改造：给月亮湾系统做“体检”和两条转型路线

6.1 上线前体检：这五个地方必须改

如果你的目标不只是交作业，而是想把这个系统写进简历或真正投入使用，建议先做一次“代码体检”。我一般按下面的清单逐项过：

这五项里，每一项都对应真实事故。明文密码是信息泄露的重灾区，SQL 拼接是注入漏洞的温床，每次新建连接会让系统在几十个并发请求下直接卡死。对一个酒店管理系统来说，客房价格、订单金额这些数据错一分钱都是事故。

6.2 转型路线：从 JDBC 到 MyBatis / Spring Boot

如果想把月亮湾系统从课设水平拔高到企业级，最平滑的路线不是重写，而是把 DAO 层逐步替换成 MyBatis。第一步不要动界面和业务逻辑，只把数据访问层换成 Mapper：

<!-- RoomMapper.xml --> <select id="findAvailableRooms" resultType="com.moonbay.model.Room"> SELECT room_id, room_no, room_type, price FROM room WHERE status = '空闲' ORDER BY room_no </select>

MyBatis 的价值在于把 SQL 和 Java 代码分离，修改查询逻辑不需要重新编译 Java 类，而且自带参数绑定，天然免疫字符串拼接注入。换成 MyBatis 之后，原本四五十行的 DAO 实现类会缩到十行以内，ResultSet手工取值的过程全部由框架完成，出错的概率大幅下降。

再往后可以引入 Spring Boot 管理事务、引入 HikariCP 连接池，甚至把界面从 Swing 换成 Vue 加 REST API。但这条改造路线最关键的一步是先把数据库设计和业务逻辑吃透，否则框架换得再新，核心的开房并发问题和房费计算误差依然存在。我做这类改造的习惯是：先跑通原系统，再动 DAO，最后才碰界面，每一步都留一个能运行的版本当后悔药。

这套月亮湾系统作为课设或许有些粗糙，但它的数据库设计和业务状态机是完整的，值得你花一个晚上从头到尾跑通、读懂、改出点名堂。希望帮到你。

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