上半年帮一个准备做毕业设计的学弟过了一遍他下载的ASP.NET酒店管理系统源码过程比我想象的曲折得多。源码能跑起来但所谓的三层架构名存实亡——页面代码里直接new SqlConnection写SQL业务层的类几乎全是空壳数据库表结构里连最基本的订单状态字段都没有。后来我自己花了两天时间把整套系统按经典三层架构完整重写了一遍从需求分析、数据库设计到DAL、BLL、UI三层逐层落地每一步都加了注释。这篇文章就是那次重写过程中沉淀下来的东西适合正在做酒店管理系统毕业设计、或者打算拿一个真实业务练手三层架构的同学。你能从里面得到一套完整的表结构设计、分层思路、核心代码示例以及不少源码下载之后根本没人告诉你的坑。1. 酒店管理系统为什么它是三层架构最理想的练手项目1.1 毕业设计里高频出现却总被做歪的需求酒店管理系统我见过很多版本有用WinForm加Access的、有直接拖GridView生成CRUD页面的、还有把整个逻辑全塞在aspx.cs代码文件里的。选这个系统做毕设的人很多但能真正讲清楚“为什么这么分层”的很少。这节先把边界掰扯清楚。酒店管理系统的核心业务其实就两条线管房源和管订单。房源这条线涉及房型、房间号、楼层、房价以及房间状态——空净房没人住且打扫干净、可以直接卖、已预订、已入住、维修中。订单这条线涉及客户信息、预订、入住登记、退房结算、取消订单。跟图书管理系统相比酒店系统的难点在于房间状态会随业务动作发生变化订单之间可能存在时间区间冲突退房时涉及费用计算。这些恰好是训练“把业务逻辑写清楚”最好的场地。1.2 三层架构和MVC不是一回事别被绕进去提起给这个系统分层最常见的误区是把三层架构和MVC画等号。三层架构的三个层是表示层UI、业务逻辑层BLL、数据访问层DALMVC是表示层内部的一种代码组织模式Model、View、Controller全都属于三层架构里的“UI层”。用一句话概括三层架构是纵向切分MVC是表现层内部的横向分工。用WebForms做三层架构界面就是aspx页面和aspx.cs后台代码用ASP.NET MVC做项目同样可以做三层只是表现层内部再按MVC细拆了一层。像“MVC三层架构”这种说法严格说不准确但课程答辩里大家习惯这么说你心里清楚区别就行。这个区分不是咬文嚼字。很多网上的源码把Controller里写满DAL查询或者把业务规则全写在GridView的RowCommand事件里最后项目根本无法维护。你先想明白每一行代码属于哪一层再开始写比下载什么源码都重要。1.3 这套系统的技术选型为什么是WebForms加ADO.NET标题写的是C# ASP.NET那默认就是一套经典组合.NET Framework 4.x ASP.NET WebForms SQL Server ADO.NET手写SQL。这是大量教材、校内课程和开源项目的默认环境也是网上几乎所有酒店管理系统源码的历史技术栈。如果你学的是ASP.NET Core思路完全平移Controller代替aspx.csEF Core代替手写SqlHelper依赖注入代替手动new BLL但三层架构的职责划分不会变。选ADO.NET而不是EF理由是这个项目要体现“三层架构”本身的价值。EF通常搭配仓储模式那是另一种讲法。手写SQL更能让人理解数据访问层到底在做什么SqlParameter为什么能防注入事务应该控制在哪一层。等这套做完你自然知道ORM帮你省了什么也更容易判断什么时候该引入Dapper这类轻量工具。2. 项目结构与分层边界先画图再写码2.1 解决方案的项目划分新建一个解决方案我习惯放四个项目职责一目了然项目名类型职责HotelSystem.UIASP.NET Web应用程序页面、控件、Session管理HotelSystem.Model类库实体类所有层共用HotelSystem.DAL类库数据访问SQL执行与结果映射HotelSystem.BLL类库业务规则、事务、对外服务实体类要不要单独建项目很多教程图省事把Model类直接放在DAL项目里。结果BLL引用DAL、UI引用BLLModel类被DAL带着往上传递项目也能跑但依赖关系里多了一条“隐形的耦合”。为了清爽我倾向独立Model项目让Model被所有层引用同时不依赖任何层。这点在后续换数据库或者拆分服务时会感谢自己。2.2 依赖方向UI依赖BLL但DAL绝对不能依赖BLL三层架构的依赖方向是单向的UI引用BLLBLL引用DALModel被所有层共同引用。有两条红线不能踩。第一BLL不能引用UI的命名空间否则表示层一改业务层也要被迫重新编译看不见的耦合就这样产生了。第二DAL不能引用BLL否则项目里会出现循环依赖编译阶段直接报错这还算幸运的真正隐蔽的是“逻辑上的反向依赖”。举个例子有人在DAL方法里直接写“如果订单不存在就抛异常”看起来只是几行校验实际上是把业务规则塞进了数据访问层。DAL应该只负责“把数据读出来、写进去”至于读出来之后该不该抛异常、要不要做判断那是BLL的职责。我在DAL方法名上会直观体现这种边界GetListByCondition、InsertEntity、UpdateState不带“是否合法”“是否允许”这类业务词。2.3 实体类设计先有表再有类建议先设计数据库表再反向生成实体类。拿三张核心表举例。Room房间表RoomId主键、RoomNo房号、RoomTypeId房型外键、Floor楼层、Price当前房费、Status房间状态。Customer客户表CustomerId、CustomerName、IdCard身份证号、Phone手机号。Orders订单表OrderId、CustomerId、RoomId、CheckInDate计划入住日期、CheckOutDate计划退房日期、RoomPrice下单时的房价快照、OrderState订单状态、CreateTime下单时间。实体类代码长这样namespace HotelSystem.Model { /// summary /// 房间实体 /// /summary public class Room { /// summary房间ID主键/summary public int RoomId { get; set; } /// summary房号例如101/summary public string RoomNo { get; set; } /// summary房间类型编号/summary public int RoomTypeId { get; set; } /// summary楼层/summary public int Floor { get; set; } /// summary当前房间挂牌价用于房态列表展示/summary public decimal Price { get; set; } /// summary房间状态0空净 1已预订 2已入住 3维修/summary public int Status { get; set; } } }为什么要有一个RoomPrice快照字段因为房价会调。客人下单的时候大床房368一晚订单住三天第二天酒店把价格调到了428退房时再去查房型价格算出来的账单会让前台和客人都很尴尬。订单表里存“下单时锁定的价格”这是做订单系统的一个基本常识也是网上一堆源码里最容易遗漏的细节。3. 数据库设计一套能跑通整个流程的表结构3.1 核心表结构与关系先给出完整的建表SQL四张表就够房型表、房间表、客户表、订单表再加一张用户表做登录。-- 房型表 CREATE TABLE RoomType ( RoomTypeId INT IDENTITY(1,1) PRIMARY KEY, TypeName NVARCHAR(50) NOT NULL, -- 大床房、标准间等 BedNum INT NOT NULL DEFAULT 1, MaxPeople INT NOT NULL DEFAULT 2 ); -- 房间表 CREATE TABLE Room ( RoomId INT IDENTITY(1,1) PRIMARY KEY, RoomNo NVARCHAR(10) NOT NULL UNIQUE, RoomTypeId INT NOT NULL REFERENCES RoomType(RoomTypeId), Floor INT NOT NULL DEFAULT 1, Price DECIMAL(10,2) NOT NULL DEFAULT 0, Status INT NOT NULL DEFAULT 0 -- 0空净 1已预订 2已入住 3维修 ); -- 客户表 CREATE TABLE Customer ( CustomerId INT IDENTITY(1,1) PRIMARY KEY, CustomerName NVARCHAR(50) NOT NULL, IdCard NVARCHAR(18) NULL, Phone NVARCHAR(20) NULL ); -- 订单表 CREATE TABLE Orders ( OrderId INT IDENTITY(1,1) PRIMARY KEY, CustomerId INT NOT NULL REFERENCES Customer(CustomerId), RoomId INT NOT NULL REFERENCES Room(RoomId), CheckInDate DATE NOT NULL, CheckOutDate DATE NOT NULL, RoomPrice DECIMAL(10,2) NOT NULL, -- 下单时房价快照 OrderState INT NOT NULL DEFAULT 0, -- 0预订 1入住 2退房 3取消 CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); -- 用户表 CREATE TABLE SysUser ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(50) NOT NULL UNIQUE, UserPwd NVARCHAR(50) NOT NULL, RoleName NVARCHAR(20) NOT NULL DEFAULT 前台 );外键这块多说一句网上的源码为了省事经常所有表都不加外键理由是“外键影响性能、麻烦”。做毕设和入门项目外键该加还是要加它能帮你挡住一部分脏数据。但要注意别把外键设计成级联删除。比如Room表想删一间房结果Orders里的历史订单也被级联删掉了这不是业务预期。我的习惯是外键保留删除动作由程序代码显式控制。3.2 状态机设计预订、入住、退房之间怎么流转这是整个系统最关键的地方也是网上下载的源码里最混乱的部分。房间状态和订单状态是两条线跟着业务动作同时变化但很多人把它们当成一个状态来管。订单状态0预订预定了还没到店、1入住客人已经在房间、2退房订单已结束、3取消。房间状态0空净、1已预订被未到店的订单占住、2已入住有客人、3维修。一个正常的流转过程如下客人电话预订客房系统生成OrderState0的订单Room.Status从0空净改为1已预订。客人到店办理入住前台在订单上点击“入住”OrderState改为1Room.Status改为2已入住。客人退房结算OrderState改为2Room.Status改回0空净。客人订单取消Room.Status恢复0空净OrderState置为3取消。你会发现Room.Status其实可以由OrderState推导出来那为什么还要在Room表里冗余一个状态字段为了查询快、显示方便。房态页面要一次性显示所有房间的状态每次都去关联订单表实时计算SQL会很繁琐页面也会卡顿。管理后台的并发量不大冗余状态完全可行但要注意状态切换必须放在同一个事务里完成否则会出现“订单已经取消房间还挂着已预订”的脏状态。3.3 日期区间查询最容易写错的地方判断房间是否可预订本质是判断“要预订的日期区间”和“已有订单的日期区间”是否相交。这里有个SQL常识两个区间[a,b]和[c,d]不相交的条件是 b c 或 a d相交的条件是 a d 且 b c。那么查询某个房间在给定区间内是否存在有效订单SQL可以这样写SELECT COUNT(1) FROM Orders WHERE RoomId RoomId AND OrderState IN (0, 1) -- 预订和入住的订单都算占用 AND CheckInDate endDate AND CheckOutDate beginDate;这里用的是 和 不是 和 这是边界条件的细节。如果业务规定退房当天中午12点前必须离店那边界还得跟着调整。总原则是写区间重叠条件之前先想清楚开闭区间不要一上来就写BETWEENBETWEEN在日期时间字段上会踩“边界落在哪一天”的坑。4. DAL层封装数据访问层只做三件事4.1 一个够用的SqlHelper就够了DAL层最基础的是封装一个SqlHelper。不用引入任何框架一个静态类三个方法就能完成90%的工作执行增删改、取单值、取DataTable。using System.Data; using System.Data.SqlClient; namespace HotelSystem.DAL { /// summary /// 通用SQL执行助手所有DAL方法都走这里 /// /summary public static class SqlHelper { // 正式项目里连接字符串应放在Web.config这里写死只是便于演示 private static readonly string ConnStr Data Source.;Initial CatalogHotelDB;Integrated SecurityTrue; /// summary /// 执行INSERT/UPDATE/DELETE返回受影响行数 /// /summary public static int ExecuteNonQuery(string sql, params SqlParameter[] pars) { using (SqlConnection conn new SqlConnection(ConnStr)) using (SqlCommand cmd new SqlCommand(sql, conn)) { if (pars ! null) cmd.Parameters.AddRange(pars); conn.Open(); return cmd.ExecuteNonQuery(); } } /// summary /// 执行SELECT返回第一行第一列常用于COUNT/MAX等聚合 /// /summary public static object ExecuteScalar(string sql, params SqlParameter[] pars) { using (SqlConnection conn new SqlConnection(ConnStr)) using (SqlCommand cmd new SqlCommand(sql, conn)) { if (pars ! null) cmd.Parameters.AddRange(pars); conn.Open(); return cmd.ExecuteScalar(); } } /// summary /// 执行SELECT返回完整结果集 /// /summary public static DataTable ExecuteDataTable(string sql, params SqlParameter[] pars) { using (SqlConnection conn new SqlConnection(ConnStr)) using (SqlDataAdapter da new SqlDataAdapter(sql, conn)) { if (pars ! null) da.SelectCommand.Parameters.AddRange(pars); DataTable dt new DataTable(); da.Fill(dt); return dt; } } } }三个方法分别对应“只增删改”“取单值”“取结果集”。注意using关键字SqlConnection和SqlCommand都实现了IDisposable用完立即释放连接这个习惯在后台服务里特别重要否则连接池会被快速耗尽。4.2 为什么必须用SqlParameter而不是拼字符串先看一个反面例子// 错误示例存在SQL注入风险 string sql SELECT * FROM Customer WHERE CustomerName name ;如果用户在文本框输入 OR 11 --拼出来的SQL变成SELECT * FROM Customer WHERE CustomerName OR 11 --等于把所有客户全查出来了。更恶劣的输入还能用分号拼接第二条更新语句或者调用xp_cmdshell执行系统命令。用SqlParameter可以彻底回避这个问题参数化查询会把输入当作“数据”而不是“SQL代码”去解析。这也是为什么DAL层所有SQL都统一走SqlParameter不要为了少写几行代码开字符串拼接的口子。4.3 DAL方法设计示例以RoomDAL为例一个最基本的数据查询方法namespace HotelSystem.DAL { /// summary /// 房间数据访问类 /// /summary public class RoomDAL { /// summary /// 根据房间ID查询房间查不到返回null /// /summary public Room GetRoomById(int roomId) { string sql SELECT RoomId, RoomNo, RoomTypeId, Floor, Price, Status FROM Room WHERE RoomIdRoomId; DataTable dt SqlHelper.ExecuteDataTable(sql, new SqlParameter(RoomId, roomId)); if (dt.Rows.Count 0) return null; DataRow row dt.Rows[0]; return new Room { RoomId Convert.ToInt32(row[RoomId]), RoomNo row[RoomNo].ToString(), RoomTypeId Convert.ToInt32(row[RoomTypeId]), Floor Convert.ToInt32(row[Floor]), Price Convert.ToDecimal(row[Price]), Status Convert.ToInt32(row[Status]) }; } } }这种“逐行取值”的写法看着繁琐但在教学项目里反而是优点你能直观看到DataRow到实体类的映射过程每个字段都有迹可循。以后想换成Dapper也就一行代码的事。先把手写映射写明白用ORM才用得心里有底。5. BLL层把业务规则从页面代码中强制剥离5.1 为什么要这个“看起来没有技术含量”的层很多人嫌BLL层代码量少觉得是摆设。我最早做三层也这样想真正出问题是在需求变更的时候。一开始预订房间只检查房间状态后来要加“同一个客户当天只能订一间房”再加“维修房不能预订”。如果这些判断全部写在页面按钮的Click事件里页面事件会越来越臃肿最后根本没法测试、没法复用。BLL的价值不在于代码多而在于它是业务逻辑的“唯一权威来源”。前台一次点击、后台给经理导数据、将来如果要做服务员App调的应该是同一个CheckRoomAvailable方法这就是复用的意义。没有BLL层同样的判断会在多个页面各写一遍改一处漏一处是迟早的事。5.2 核心业务规则代码预订房间的核心方法我写在RoomBLL里namespace HotelSystem.BLL { /// summary /// 房间业务逻辑类 /// /summary public class RoomBLL { RoomDAL roomDal new RoomDAL(); OrderDAL orderDal new OrderDAL(); /// summary /// 判断房间在指定时间段内是否可预订 /// /summary /// param nameroomId房间ID/param /// param namebeginDate计划入住日期/param /// param nameendDate计划退房日期/param /// returnstrue表示可预订/returns public bool CheckRoomAvailable(int roomId, DateTime beginDate, DateTime endDate) { // 第一步房间状态必须为空净 Room room roomDal.GetRoomById(roomId); if (room null) return false; if (room.Status ! 0) return false; // 第二步时间区间内不能存在未结束的有效订单 int exists orderDal.CountConflictOrders(roomId, beginDate, endDate); return exists 0; } } }这个方法就是业务规则的代表一次预订请求能否成功包含两个检查点每个检查点都可以单独写单元测试。这在没有BLL的年代是根本做不到的——测试只能开浏览器点按钮全靠肉眼判断。5.3 业务异常怎么把“不能预订”的原因告诉用户业务规则失败不能靠返回false让UI层猜原因。false有可能是因为房间不存在有可能是因为状态不对也有可能是时间冲突调用方什么都不知道。我的做法是自定义一个业务异常namespace HotelSystem.BLL { /// summary /// 业务规则校验失败异常Message可以直接展示给用户 /// /summary public class BusinessException : Exception { public BusinessException(string message) : base(message) { } } }BLL方法里该抛就抛if (room.Status ! 0) { throw new BusinessException(该房间当前状态不可预订请刷新后重试。); }UI层在按钮事件里包一层try-catch捕获BusinessException后把异常消息展示出来其他异常记录日志后给一个通用提示。这样用户看到的是“该房间已被预订请选择其他房型”而不是一屏黄色的调试错误页。6. UI层实现登录、房态管理、预订退房全流程6.1 登录模块从TextBox到Session登录页本身不复杂重要的是登录之后的状态管理。代码protected void btnLogin_Click(object sender, EventArgs e) { string userName txtUserName.Text.Trim(); string pwd txtPwd.Text.Trim(); UserBLL bll new UserBLL(); User user bll.Login(userName, pwd); if (user null) { lblMsg.Text 用户名或密码错误; return; } Session[CurrentUser] user.UserName; Response.Redirect(Default.aspx); }登录成功后把用户标识放Session里这是WebForms管理会话的常规套路。注意密码存储问题上面那张SysUser表里直接存了明文密码毕设演示可以真实系统必须用哈希加盐。这里强调一下不要学明文密码。Session有个经典的坑默认Timeout约20分钟长时间不操作会过期过期后Session[CurrentUser]是null直接访问业务页面就会抛空引用异常。解决办法最简单的是在MasterPage的Page_Load里统一判断if (Session[CurrentUser] null) { Response.Redirect(Login.aspx); }6.2 房态管理让GridView不只是表格房态页面用GridView显示所有房间每一行根据房间状态显示不同颜色。颜色区分状态用RowDataBound事件protected void gvRooms_RowDataBound(object sender, GridViewRowEventArgs e) { if (e.Row.RowType ! DataControlRowType.DataRow) return; int status Convert.ToInt32(DataBinder.Eval(e.Row.DataItem, Status)); switch (status) { case 0: e.Row.BackColor System.Drawing.Color.LightGreen; break; case 1: e.Row.BackColor System.Drawing.Color.LightYellow; break; case 2: e.Row.BackColor System.Drawing.Color.LightCoral; break; default: e.Row.BackColor System.Drawing.Color.LightGray; break; } }数据绑定的时候GridView要设置DataKeyNamesRoomId这样操作按钮才能知道当前行对应的是哪个房间。前台看到的不再是一堆毫无意义的数字而是“绿的是能卖、黄的是有人预订了、红的是已入住”这是房态管理页面最基本的要求。6.3 预订、入住、退房一套完整业务流程的页面串联预订页面的保存按钮逻辑是这样的选房型、查可用房间、填客户信息、生成订单。关键代码protected void btnSaveOrder_Click(object sender, EventArgs e) { int roomId Convert.ToInt32(ddlRooms.SelectedValue); DateTime begin Convert.ToDateTime(txtBegin.Text.Trim()); DateTime end Convert.ToDateTime(txtEnd.Text.Trim()); RoomBLL roomBll new RoomBLL(); OrderBLL orderBll new OrderBLL(); try { if (!roomBll.CheckRoomAvailable(roomId, begin, end)) { lblMsg.Text 该房间在所选时间段内不可预订; return; } int orderId orderBll.CreateOrder( txtCustomerName.Text.Trim(), txtIdCard.Text.Trim(), txtPhone.Text.Trim(), roomId, begin, end); lblMsg.Text 预订成功订单号 orderId; } catch (BusinessException ex) { lblMsg.Text ex.Message; } }退房结算比预订稍复杂它涉及费用计算。房费规则要提前定清楚住几晚每晚多少钱。“住几晚”的计算细节我这里的约定是CheckInDate和CheckOutDate存的是日期退房当天不计房费所以房间费等于“退房日期减入住日期的天数乘以房间单价”。这个计算放BLL不放在页面里。结算流程大致是加载订单、计算房费、计算押金抵扣与退款、把OrderState置为2、把Room.Status改回0空净。这些动作同样放在一个事务里执行。7. 带注释源码的阅读方法与调试经验7.1 好注释解释“为什么”坏注释解释“是什么”很多下载下来的源码注释长这样“声明一个整数变量”“获取名字”——这种注释写了等于没写。我写注释的原则是每一处需要超过5秒钟才能想明白的代码都写一句注释解释当时的思考。比如订单表里为什么存RoomPrice注释我会这么写// 注意这里存的是下单时的房间价格快照不是Room表当前价格。 // 如果客人订房后酒店调价结算必须按下单时的价格避免前台算糊涂账。SqlParameter同理// 必须用参数化查询不能字符串拼接。 // 用户输入 OR 11-- 会把条件绕过这是经典的SQL注入手段。这种注释写的是“为什么这么设计”“这里有什么坑”比单纯描述动作有用一百倍。带注释源码真正值钱的地方恰恰就是这些“设计原因”。7.2 拿到一份源码后的三步跟进法第一步先把数据库脚本跑起来然后把Web.config里的连接字符串改成你自己机器的配置。很多源码第一次跑不起来九成是连接字符串没改对。第二步找一个你最熟悉的业务比如“预订房间”沿“预订页面→BLL方法→DAL方法→SQL语句”这条线走一遍。关键是找对入口先从页面源码找一个Button的Click事件而不是凭感觉猜功能点。页面的目录结构就是功能的导航图。第三步在BLL方法入口打断点看入参和返回结果。如果入参已经不对问题一定在前面如果BLL参数正常但返回结果不对再往下看DAL和SQL。7.3 最常用的三个调试技巧第一个断点打在BLL方法的第一行。BLL是业务规则的裁决点在这里能看到调用方传来的参数到底对不对也能看到DAL返回的数据长什么样。第二个异常不要只盯着Message看。Visual Studio的“调用堆栈”窗口会告诉你是哪一行抛出来的顺着调用栈从下往上读很容易定位是三层里哪一层出了问题。第三个SQL执行结果不确定时打开SQL Server Management Studio把DAL里的SQL手动执行一遍。问题到底在C#代码还是在SQL逻辑一次就能分清楚。8. 编译、部署与常见异常排查8.1 环境准备最容易忽略的三件事环境版本不对经常在按下F5之前就劝退新人。三件事最常见。第一Visual Studio打开项目后提示“无法加载项目”。原因通常是目标框架和本地安装的组件不匹配。建议装VS 2017以上的版本勾选“.NET桌面开发”和“ASP.NET和Web开发”两个工作负载。第二SQL Server服务没启动表现为“在建立与服务器的连接时出错”。去Windows服务里看SQL ServerMSSQLSERVER有没有启动启动后还要确认一下TCP/IP协议是否启用。第三数据库账号与连接字符串。本机开发用Windows身份验证最省事连接字符串里的Data Source要写对默认实例写“.”命名实例写成“.\SQLEXPRESS”这样的形式。Initial Catalog要和实际数据库名一致。8.2 运行期常见异常对照表异常信息最可能的根因排查思路在建立与服务器的连接时出错连接字符串错误或SQL Server服务未启动检查Data Source、Initial Catalog确认服务已启动对象名‘dbo.xxx’无效当前连接的数据库不是目标库或表未创建检查Initial Catalog确认建库脚本已执行未将对象引用设置到对象的实例Session为null或DataRow为null在BLL方法入口断点看入参和null来源列名‘Xx’无效实体类字段和表字段不一致对照实体属性与表结构逐字段检查无法加载文件或程序集System.Web.Mvc相关NuGet包未安装或版本不一致还原NuGet包或手动引用对应DLL这里特别说一个心态问题看到“未将对象引用设置到对象的实例”别慌它90%的情况是某一处返回值是null。你在报错那一行能看到是哪个变量为null再往回找它为什么没有值基本就定位了。空引用不是玄学是某个“本该有数据的查询”查出了空结果顺着调用链往回走总比乱改上传参数强得多。8.3 交付一份能加分的毕设项目清单最后多说一嘴项目交付。酒店管理系统不管下载还是自己写都不算完关键是能产出“说清楚”的交付物。建议按这个清单准备数据库创建脚本和初始数据脚本让老师一键建库。可编译运行的全部源码注释按“为什么”的标准写。项目架构说明文档画三层架构图列出各层职责和引用关系。核心流程文档重点说订单与房间状态在预订、入住、退房时的流转。测试用例和演示账号展现功能覆盖度。答辩的时候这些材料比一张花里胡哨的界面更能说服老师。等你照着这套流程做完再回头看那些从网上随手下的所谓带注释源码你会发现很多代码其实只是把SQL写在页面里、把状态判断到处罗列的“面条代码”。你能看懂它们为什么不对知道每一行代码该归属哪一层这个毕设才算真正做完了。