简介：一套基于C#与SQL Server开发的酒店管理系统完整源码，包含前台界面与后台数据库脚本，面向计算机相关专业毕业生、C#与数据库开发者。系统采用三层架构，覆盖客户管理、房间预订、入住退房、财务统计等核心模块，可直接作为毕业设计参考，也适合学习者对照项目理解WinForms开发中的数据交互与业务分层。压缩包共55个文件，以C#源代码（cs）、数据库脚本（sql）、界面资源（resx/resources）为主，兼含可执行文件（exe）、项目配置文件（config/sln/csproj）和README说明，整体约1.15MB，结构紧凑。当前已有232人学习下载。借助源码可掌握实际开发中的编码规范、设计模式、数据库建表与查询技巧，并可由SQL脚本快速还原数据库，结合项目说明快速跑通系统；对完成毕设或积累实战经验均具价值。
1. 毕业设计选酒店管理系统：这个 C# 项目比想象中更能打
毕业设计要选一个能落地、能讲清、还能拿得出手的题目，酒店管理系统是最常被点名的方向之一。它不追求花哨算法，但把用户登录、房间状态、预订、入住退房、账单和报表全串起来了，正好覆盖一个完整信息系统的所有关键环节。这套基于 C# 开发的酒店管理系统，配好 SQL Server 数据库和完整源码，属于拿过来就能跑、跑完能讲、讲完能改的实用资源。比起从零搭框架，更适合需要快速产出可演示作品的人。新手能顺着工程结构学会分层写法，熟手可以跳过重复造轮子，直接盯业务逻辑和边界问题。
2. 先拆工程结构：三层架构与文件布局决定了你能改多深
2.1 三层架构不只是概念，看调用关系就懂了
这套系统的架构在摘要里写得很清楚：表示层 UI、业务逻辑层 BLL、数据访问层 DAL。很多同学在简历上写「熟悉三层架构」，但真被问到「你项目里的 BLL 和 DAL 是怎么分工的」就卡壳。在这个项目里，你打开源码能直接看到这种分工落地后的样子。
表示层只管两件事：把界面画出来、把用户的操作传给下一层。登录按钮点下去之后，窗体本身不会直接碰数据库，它调用的是业务逻辑层的方法。业务逻辑层拿到用户名和密码，先做规则判断（比如空值检查、长度校验），再决定下一句该问谁要数据。数据访问层最底层，负责把 SQL 语句发给 SQL Server，把查询结果转成 C# 能用的对象返回给上层。
这个调用链是单向的：UI → BLL → DAL。在实际代码里你会发现，查询房间列表时，UI 层只需要调用一个类似GetRoomList()的方法，完全不用关心这个方法内部是拼接了字符串还是用了存储过程。这种隔离带来的直接好处是：如果你想从 WinForms 改成 Web 界面，业务逻辑和数据访问代码可以原封不动地搬过去。毕业设计答辩时，导师问到「系统可扩展性体现在哪里」，回答这个调用关系比背概念强得多。
2.2 文件与源码包：拿到压缩包后先分清哪些该看、哪些别乱动
压缩包里的文件清单不算复杂，但第一次打开的人容易懵。HotelManagement-master是工程主目录，目录名带master说明是从 Git 仓库打包出来的，正常情况下源码就在这里面。C#前台这个文件夹名看着像资源文件，实际操作时你要找的是主工程文件（.sln或.csproj），它就放在主目录下。icon.ico和loginbg.jpg是程序图标和登录背景图，属于视觉资源，编译时会被嵌入程序里。
sql server数据库目录和sql server.sql脚本是重头戏。前者可能是附加用数据库文件（.mdf／.ldf），后者是纯 SQL 脚本，两种方式都能把数据库恢复出来。README.md 是作者写的说明文件，我的习惯是拿到任何项目先把 README 完整读一遍，里面通常会写环境要求、默认账号、连接字符串位置这类救命信息。
文件不要乱动的地方是bin和obj目录。bin下放的是编译产物，obj是中间文件，这两个目录在任何情况下都不需要手动编辑。如果你看到工程打不开，第一反应应该是检查.sln文件而不是去翻 bin 里的 DLL。源码根目录下如果有packages文件夹，说明项目用了 NuGet 依赖包，还原包时注意网络环境。
2.3 版本选型：Visual Studio 与 SQL Server 组合决定第一次运行成功率
打开.sln文件时，Visual Studio 会提示「版本不兼容」或直接拒绝加载，这是最常见的翻车现场。原因通常在项目文件里指定的 SDK 版本和你本机装的不一致。这个项目用的是 C# + .NET Framework 技术栈，对应的是 Windows 平台上的 Visual Studio，不是 VS Code。社区版就够用，不需要许可证。
SQL Server 的版本选择上，我一般建议优先装 SQL Server Express 或 Developer 版，因为功能上跑这种规模的毕业设计绰绰有余，而且资源占用比企业版小得多。连接数据库时先用 Windows 身份验证登录，等确认数据库能正常附加和查询后，再考虑要不要切 SQL Server 身份验证。混合认证模式需要在安装时就勾选，装完再切换要动注册表和服务配置，对新手来说容易卡住。
如果附加数据库时提示「版本高于当前实例」，说明 SQL Server 装得太新或太旧。常见做法是把.mdf文件拿到低版本 SQL Server 上附加，然后用生成脚本的方式导出，再导入到新实例里。另一种更省事的方案是直接在目标机器上运行sql server.sql脚本重建数据库，绕开附加版本问题。
3. 数据库设计与 SQL 脚本：房间状态怎么流转全看表怎么设计
3.1 核心表设计与关系：从用户表到账单表的链路
酒店管理系统里最核心的表不是用户表，而是房间表和预订表，因为它们之间的状态流转直接决定了系统逻辑。房间表存的是客房的基本属性：房间号、类型、价格、楼层、状态。状态字段是关键，通常用数字或字符串标记：空房、已预订、已入住、清洁中。预订表则保存客户与房间之间的关系，记录入住人、预订时间、预计入住和离店日期。
客户表用来存客户信息，姓名、电话、证件号，还有预订历史。用户表管的是员工账户，区分管理员和前台操作员，权限控制就在这一层。账单表记录每一笔消费，包括房费、押金、其他消费项和最终结算金额。这几张表的关系很直接：客户可以多次预订，一次预订对应一个房间，退房时生成一条账单记录。
在这个项目的 SQL 脚本里，你会发现表名和字段名基本是 Camel 风格命名，比如RoomID、CustomerName、ReservationDate。命名规范统一对后续写 C# 代码很友好，因为 C# 里的属性命名风格和这完全一致，省去了大量字段映射的体力活。数据库里尽量别用中文表名和字段名，虽然 SQL Server 支持中文标识符，但混在 C# 代码里容易踩编码坑。
3.2 建表脚本与种子数据：直接跑通基础数据
拿到sql server.sql脚本后，直接在 SQL Server Management Studio 里打开执行即可。如果脚本里带了CREATE DATABASE语句，它会自动建库和建表；如果只建表不建库，你需要自己先新建一个数据库，然后切换上下文再执行。判断方法很简单：看脚本开头有没有CREATE DATABASE关键字。
-- 创建房间表 CREATE TABLE dbo.Room ( RoomID INT IDENTITY(1,1) PRIMARY KEY, -- 房间自增ID RoomNo NVARCHAR(10) NOT NULL, -- 房间号，例如 101、202 RoomType NVARCHAR(20) NOT NULL, -- 房间类型：单人间/标准间/套房 Price DECIMAL(10,2) NOT NULL, -- 房价，保留两位小数 FloorNo INT DEFAULT 1, -- 所在楼层 RoomStatus INT DEFAULT 0 -- 0空闲 1已预订 2已入住 3清洁中 ); GO -- 插入几条种子数据，保证登录后能看到房间列表 INSERT INTO dbo.Room (RoomNo, RoomType, Price, FloorNo, RoomStatus) VALUES ('101', N'单人间', 168.00, 1, 0), ('202', N'标准间', 268.00, 2, 0), ('305', N'套房', 568.00, 3, 0); GO这段脚本里IDENTITY(1,1)表示房间号自增，从 1 开始每次加 1。DECIMAL(10,2)是货币字段的常规选择，避免浮点误差。NVARCHAR带 N 前缀是为了支持中文，如果是纯英文系统可以换成VARCHAR，但中文界面的项目一律用NVARCHAR。种子数据不能省略，否则第一次打开程序时房间列表是空的，你会怀疑是代码没跑通。
实际项目中，用户表必须有一条默认管理员记录，不然登录界面永远进不去。在脚本里你大概率能看到默认账号，常见的是admin/123456，或者admin/admin。拿到手第一件事就是查这条记录，并立刻把默认密码改掉。这是安全习惯，也是答辩时提出来加分的点。
3.3 外键关系与删除策略：级联删除要慎用
房间表、预订表、客户表、账单表之间要有外键约束，这套系统的脚本里应该已经定义好了。外键的作用是保证数据一致性：你不允许删除一个已被预订记录引用的客户，除非先清理预订记录。删除策略通常有三种：默认阻止、级联删除、置空。
毕业设计场景里，我建议把删除策略设置成「阻止」。也就是说，如果某个客户有历史预订和账单，前台人员不能在界面上直接删掉他，只能标记为停用。级联删除表面省事，但一旦误删，会把整个链条上的账单记录一并干掉，数据找不回来，这个坑在调试阶段尤其折磨人。
ALTER TABLE dbo.Reservation ADD CONSTRAINT FK_Reservation_Room FOREIGN KEY (RoomID) REFERENCES dbo.Room(RoomID) ON DELETE NO ACTION; -- 有预订记录时，禁止删除房间ON DELETE NO ACTION表示当房间在预订表里仍被引用时，删除操作会被数据库拒绝，并抛出外键冲突错误。这个错误在代码里会被 BLL 层捕获并翻译成「该房间存在预订记录，无法删除」的友好提示。如果脚本里没写这句，默认就是 NO ACTION，不需要额外加。
3.4 连接字符串配置：改错一个单词就白跑
C# 连接 SQL Server 的连接字符串通常写在一个叫App.config或web.config的文件里。打开配置文件，你会看到一小段像Data Source=.;Initial Catalog=HotelDB;User ID=sa;Password=123456这样的文本。如果这个项目是直接写死在代码里的，建议改成从配置文件读取，方便后续换库。
<connectionStrings> <add name="HotelDB" connectionString="Data Source=.;Initial Catalog=HotelDB;Integrated Security=True;" providerName="System.Data.SqlClient" /> </connectionStrings>Data Source=.表示本机 SQL Server 默认实例。如果装了命名实例，比如SQLEXPRESS，要写成Data Source=.\SQLEXPRESS。Initial Catalog是数据库名，必须和脚本里建的库名一致。Integrated Security=True表示用 Windows 身份验证，适合开发环境；部署到别的机器时，改成User ID=sa;Password=xxx并且确认 SQL Server 开了混合认证模式。
在DAL层代码里读取连接字符串时，常见写法是ConfigurationManager.ConnectionStrings["HotelDB"].ConnectionString。如果编译报错说找不到ConfigurationManager，需要在项目里引用System.Configuration程序集，这是新手容易漏掉的一步。
4. 核心功能实现：登录、房间办理与退房结账代码解析
4.1 登录验证：从 CheckBox 到数据库比对
登录模块是系统的门面，也是被怼概率最高的模块。正常的流程是：用户在窗体输入账号密码，选择角色，点登录按钮后，程序先做本地校验，再查数据库比对。
private void btnLogin_Click(object sender, EventArgs e) { string userName = txtUserName.Text.Trim(); string passWord = txtPassWord.Text.Trim(); // 本地空值校验，不进数据库 if (string.IsNullOrEmpty(userName) || string.IsNullOrEmpty(passWord)) { MessageBox.Show("用户名和密码不能为空！"); return; } UserService userService = new UserService(); User loginUser = userService.Login(userName, passWord); if (loginUser != null) { // 登录成功，保存当前用户对象到全局变量 GlobalInfo.CurrentUser = loginUser; this.Hide(); new MainForm().Show(); } else { MessageBox.Show("用户名或密码错误！"); } }这段代码的Text.Trim()是为了去掉用户输入首尾的空格，防止手滑多敲了一个空格导致登录失败。UserService是业务逻辑层的服务类，Login方法内部会调用 DAL 层查询数据库。GlobalInfo.CurrentUser是一个静态类里的静态属性，用来在整个程序生命周期里保存当前登录用户的信息，主窗口和其他窗体都能访问到它。
讲一下这个设计思路：把「登录成功之后谁能看到哪个界面」这种规则放在 BLL 层，而不是散落在各个窗体里，可以避免大量重复判断。比如管理员登录后能看到员工管理菜单，前台操作员登录后看不到，这些判断集中在主窗体的加载事件里，代码看起来清爽，也方便后续扩展更多角色。
4.2 房间状态查询与预订：下拉框联动与参数化查询
房间管理窗体是使用频率最高的界面。前台人员需要按房间类型筛选空房，选中后执行预订操作。这个功能在 DAL 层往往会有参数化查询方法，目的是防止 SQL 注入。
public List<Room> GetAvailableRooms(string roomType) { List<Room> rooms = new List<Room>(); string sql = "SELECT * FROM Room WHERE RoomStatus = 0 AND RoomType = @RoomType"; using (SqlConnection conn = new SqlConnection(connString)) { SqlCommand cmd = new SqlCommand(sql, conn); cmd.Parameters.AddWithValue("@RoomType", roomType); conn.Open(); using (SqlDataReader reader = cmd.ExecuteReader()) { while (reader.Read()) { Room r = new Room { RoomID = Convert.ToInt32(reader["RoomID"]), RoomNo = reader["RoomNo"].ToString(), RoomType = reader["RoomType"].ToString(), Price = Convert.ToDecimal(reader["Price"]), FloorNo = Convert.ToInt32(reader["FloorNo"]), RoomStatus = Convert.ToInt32(reader["RoomStatus"]) }; rooms.Add(r); } } } return rooms; }@RoomType是参数化查询的占位符，AddWithValue会把下拉框选中的值打包成 SQL 参数传给数据库。这样做的好处是，即使用户输入' OR 1=1 --这种恶意字符串，也会被当成普通文本处理，而不是被拼进 SQL 语句。开发环境里图省事直接字符串拼接 SQL 的方式，系统功能上好像没问题，但到了毕业设计答辩演示现场，一旦有人提到 SQL 注入，这就是说不清的技术债务。
下拉框这里，我在做类似项目时习惯把「请选择房间类型」作为默认项，值为空字符串。这样用户不选类型直接点查询时，DAL 层方法会查询所有空房；选了一类就只查那一类。在 UI 层拿到返回的房间列表后，DataGridView 的数据源直接绑定 List，刷新列表只需要重新调用一次查询方法。
4.3 退房结账与账单生成：事务与状态联动的关键节点
退房是酒店管理系统里最容易出逻辑漏洞的地方。它涉及两件事：根据停留天数算房费、把房间状态从已入住改成空房。如果先更新房间状态再生成账单，万一账单生成失败，房间已经是空房了，财务数据却丢了；反过来先记账后改状态，万一状态更新失败，房间还占着，前台就发现不了问题。
public bool CheckOut(int roomId, int reservationId, decimal totalAmount) { using (SqlConnection conn = new SqlConnection(connString)) { conn.Open(); SqlTransaction tran = conn.BeginTransaction(); // 开启事务 try { string updateReservationSql = N"UPDATE Reservation SET CheckOutDate = GETDATE(), TotalAmount = @Amount WHERE ReservationID = @ResvID"; SqlCommand cmd1 = new SqlCommand(updateReservationSql, conn, tran); cmd1.Parameters.AddWithValue("@Amount", totalAmount); cmd1.Parameters.AddWithValue("@ResvID", reservationId); cmd1.ExecuteNonQuery(); string updateRoomSql = "UPDATE Room SET RoomStatus = 0 WHERE RoomID = @RoomID"; SqlCommand cmd2 = new SqlCommand(updateRoomSql, conn, tran); cmd2.Parameters.AddWithValue("@RoomID", roomId); cmd2.ExecuteNonQuery(); tran.Commit(); // 全部成功，提交事务 return true; } catch { tran.Rollback(); // 任一步失败，回滚所有操作 return false; } } }这里的关键点是SqlTransaction，它把两个 SQL 操作绑到一个原子动作里。tran.Commit()只有在两条语句都执行成功后才调用，任何异常都会触发Rollback()，把数据库回滚到退房前的状态。这种写法值得在答辩时单独强调，因为很多管理系统的初级版本压根没处理跨表操作的原子性。
总金额的计算通常放在 BLL 层，从预订信息里取出房价和入住天数，再加上额外的消费项（如迷你吧、损坏赔偿），得到最终账单。这个项目里账单表单独设计的话，退房时还需要向账单表插入一条记录。界面上一般会有一个「押金收款」按钮，收完押金后押金余额字段更新，结账时用押金冲抵房费，多退少补的逻辑要放清楚。
5. 运行避坑与排查：从 SQL Server 到界面资源的重复问题
5.1 坑一：混合认证模式没开启，程序怎么都连不上数据库
现象：数据库明明在 SSMS 里能看到，程序运行时却弹出「用户 'sa' 登录失败」。 原因：SQL Server 默认安装的情况下，Windows 身份验证模式只允许本机 Windows 账户登录。程序里连接字符串用了User ID=sa，但服务器没开混合认证，所以拒绝登录。 解决：用 Windows 身份验证登录 SSMS，右键服务器节点 → 属性 → 安全 → 选择「SQL Server 和 Windows 身份验证模式」，然后重启 SQL Server 服务。重启服务可以在服务管理器里操作，也可以在 SSMS 里右键服务器选择「重新启动」。改完之后再试连接，同时确认sa账号的密码策略没有被强制锁定。
这个操作在开发环境里做完一次就再也不会遇到，但换一台机器部署时基本会重新踩一遍。我习惯在项目的 README 里写清楚这一步，省得换个环境又抓瞎。
5.2 坑二：数据库附加失败，提示版本不兼容或文件已损坏
现象：双击.mdf文件尝试附加，SSMS 报错，说数据库版本高于当前 SQL Server 实例支持的最高版本。或者提示文件已损坏，无法附加。 原因：项目里的数据库是用高版本 SQL Server（例如 2019）生成的，本机装的是低版本（例如 2012），数据文件格式不兼容。还有一种情况是.mdf文件是从压缩包里直接解压的，解压过程中被安全软件拦截或者没有完全解压出来。
解决：先在正确版本上附加一次并导出脚本，这是最稳的路径。如果你有高版本 SQL Server 的环境，附加后用「任务 → 生成脚本」把库结构导成.sql文件，然后拿到低版本上执行。另一种更快的补救方式是直接用sql server.sql脚本在当前库上重建表结构和种子数据，适合对数据要求不高的场景。遇到安全软件拦截可以先把整个压缩包加入信任区再解压。
5.3 坑三：删除房间时外键约束报错，编译器说你"违反冲突"
现象：界面上点击删除一个房间，程序弹出一个看着像崩溃的异常窗口，提示The DELETE statement conflicted with the REFERENCE constraint。 原因：该房间在预订表里仍然存在关联记录，数据库按照外键约束阻止了删除操作。程序在 DAL 层没有做友好捕获，直接抛出了原生异常。 解决：删改数据前先做存在性检查。例如给房间表的删除加一个前置查询：如果预订表里存在该RoomID的记录，就不允许删除并提示「该房间存在历史订单，无法删除」。做这次修复时建议同时给系统里所有删除操作统一加上这层检查，不仅是房间表。否则客户删除、员工删除一样会触发这种原生异常。
5.4 坑四：启动程序后图标和背景图不显示，甚至窗体加载直接报错
现象：程序编译通过，但运行时控制台（如果是窗体程序则是窗体）加载明显异常，要么登录背景一片灰，要么弹错找不到命名空间下某个资源。 原因：icon.ico和loginbg.jpg这类文件被遗漏在工程目录外，或者文件属性没有被设置为Content/Resource。在项目文件里如果资源文件没有被引用，编译后的程序集里就找不到对应的嵌入资源。 解决：在解决方案资源管理器里右键出错的文件 → 属性 → 生成操作设为Resource或Content，复制到输出目录选「始终复制」。如果是图片路径硬编码在代码里（比如写死成C:\temp\loginbg.jpg），改成相对路径或嵌入资源方式。正规做法是把资源文件放到Resources文件夹中，用项目属性里的资源管理器统一打理。
5.5 坑五：界面中文乱码，数据库里全是问号
现象：程序界面上所有中文正常显示，但数据库表里存进去的中文变成????，或者反过来，数据库里的中文显示正常，程序界面上乱码。 原因：客户端与数据库Types不匹配。客户端传递给 SQL Server 的参数用的是VARCHAR，而数据库字段是NVARCHAR，导致中文在编码转换中丢失。也可能是 SQL 脚本执行时用的字符集和程序运行时不一致。 解决：和参数相关的 SQL 语句统一用NVARCHAR参数类型。例如cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = name;，不要用AddWithValue让它自己猜类型。建表时敏感字段一律NVARCHAR，避免类型隐式转换。这种问题排查时会花掉很长时间，如果你还没开始改代码，先核对脚本里的字段类型和代码里的参数类型是否一致，能省不少时间。
6. 进阶操作：给这个工程加一层答辩安全感——日志、备份与一键初始化
拿到这套系统，跑通只是第一步，能应对现场的提问才叫真正吃透。我给A同学做这类毕业设计复盘时，会刻意让他做三件事：第一，加一个登录日志表，每次成功登录都写入账号、时间、IP（或机器名）；第二，写一个备份脚本，一键把数据库导出为.bak文件；第三，在程序里做一个「一键重置数据」的管理员功能，把预订表、账单表清空，只保留基础种子数据。
登录日志表很简单，就是一张LoginLog表，字段包括LogID、UserName、LoginTime、MachineName。在Login方法成功返回用户对象后，再调用一次LogService.AddLoginLog(...)。这个功能除了答辩时好看，还有一个现实价值：如果多个人用同一个管理员账号操作，出了问题能追溯到是谁在什么时间登录的。很多原版系统不提供日志，你加上去之后，系统完整度是两个档次。
数据库备份脚本放到服务端定时执行也可以，但毕业设计现场演示时，让导师看到你有一个「一键备份」按钮更有冲击力。在管理菜单里加一个按钮，后台调用SqlBackupDatabase，把当前数据库备份到指定路径。演示时你可以现场点一下，然后打开文件管理器展示.bak文件的时间和大小。这一手比讲十分钟架构更能让人信服你把系统当回事。
从那以后我每次拿到外包项目或毕设工程，都强制自己先跑通带日志和备份的完整链路，再回头看业务代码。日志、备份和事务是三个永远不会过时的安全网。希望这些拆解能帮你在这个 C# 酒店管理系统上少走点弯路，花时间在真正有用的地方。
本文还有配套的精品资源，点击获取
