第一次接触酒店管理系统，是在某个模拟课程设计里：老师给了个题目，叫"基于ASP.NET的酒店管理系统"，要求C#写后台，SQL Server存数据，用三层架构。我在网上翻了一圈源码，发现大量所谓"三层架构"项目，实际上就是把SQL语句写在aspx页面的后台代码里，业务逻辑全堆在按钮的Click事件中。那种项目交作业没问题，但真拿去给前台用，改一个房态逻辑能改到怀疑人生。

这篇文章我想认真梳理一遍，用ASP.NET + C# + SQL Server做一套酒店管理系统，三层架构到底该怎么拆、数据库怎么建模、预订入住退房这些核心流程怎么落地，以及中途踩过的那些坑。不管是做课程设计、毕业设计，还是公司内部要搭一套简化版的房管系统，这篇都能给你一条可以照着走的路。

1. 酒店管理系统的真实业务范围：先搞清楚"管什么"再谈代码

很多人一拿到题目就开始建表建项目，结果做着做着发现漏了功能。我做这类系统之前，习惯先列一遍酒店前台的实际工作流：客人进店 -> 问有没有房 -> 看房型看价格 -> 下单入住 -> 住几天 -> 退房结账。中间还穿插电话预订、修改预订、取消预订、换房、续住、押金管理，以及老板每天要看的出租率、营业额报表。

1.1 核心模块清单与边界划分

把这套流程映射成系统模块，至少包括以下六块：

• 客房管理：房型维护、房间档案、房间状态管理（空闲、已预订、已入住、脏房、维修房）。
• 客人管理：散客信息登记、会员信息维护、身份证号、联系方式、历史入住记录。
• 预订管理：在线/电话预订、预订确认、预订取消、预订转入住。
• 前台收银：入住登记、退房结算、押金收取与退还、换房差价计算、续住计费。
• 报表统计：房间出租率、收入报表、客源分析、房态总览。
• 系统管理：登录认证、操作员账号、角色权限、数据备份。

这里有个容易被忽略的点：房间状态不能只做一个"空闲/占用"的布尔字段。真实酒店里，"脏房"和"维修房"是两种完全不同的状态——脏房是客人退房了但还没打扫，能卖但得等保洁；维修房是空调坏了、水管漏了，暂时锁房。如果只用一个字段，你没法区分"这间房是能卖但没打扫，还是不能卖"。我建议状态字段用枚举值，预留扩展位，后面我给出具体设计。

1.2 为什么这套系统天然适合三层架构

三层架构在ASP.NET时代被反复提及，不是因为它是银弹，而是因为酒店管理系统的业务特性正好吃这套结构：

• 表现层（UI）：负责和用户交互，包括aspx页面展示、输入校验、界面跳转。它只关心"我显示什么、用户点了什么"。
• 业务逻辑层（BLL）：负责业务规则，比如"预订时房间必须空闲""退房时房费按小时算还是按天算""会员能不能打折"。这些规则不因页面变化而改变。
• 数据访问层（DAL）：只负责增删改查，把SQL语句封装起来，向外提供方法。

我见过最典型的反面例子：直接在aspx.cs里写string sql = "SELECT * FROM Room WHERE RoomNo='" + txtRoomNo.Text + "'";，然后SqlCommand一执行就把结果绑给GridView。这样做开发速度确实快，但一旦你要换数据库、加权限、改业务规则，就得在所有页面里翻代码。三层架构的核心价值不是什么高深理论，而是：页面只管交互，规则管规则，数据管数据。改任何一层，另外两层尽量不碰。

2. SQL Server数据库建模：房态、订单、价格计划是关键

数据库设计直接决定系统上限。很多半成品系统的失败都败在表结构上：审批流没有、价格变化没法追溯、换房记录丢失、退房和订单对不上账。

2.1 核心表结构与字段说明

我常用的表结构，去掉冗余字段，核心就这几张：

-- 房型表 CREATE TABLE RoomType ( TypeId INT PRIMARY KEY IDENTITY(1,1), TypeName NVARCHAR(50) NOT NULL, -- 如：标准单人间、豪华双人间 BedNum INT NOT NULL DEFAULT 1, -- 床位数 BasePrice DECIMAL(10,2) NOT NULL, -- 挂牌价 Area DECIMAL(8,2), -- 面积，部分报表会用到 Remark NVARCHAR(200) ); -- 房间表 CREATE TABLE Room ( RoomId INT PRIMARY KEY IDENTITY(1,1), RoomNo NVARCHAR(20) NOT NULL UNIQUE, -- 房间号，如 1201 TypeId INT NOT NULL REFERENCES RoomType(TypeId), Floor INT NOT NULL, -- 楼层，便于按楼层查房态 Status TINYINT NOT NULL DEFAULT 0, -- 0空闲 1已预订 2已入住 3脏房 4维修 Remark NVARCHAR(200) ); -- 客人表 CREATE TABLE Customer ( CustomerId INT PRIMARY KEY IDENTITY(1,1), CustomerName NVARCHAR(50) NOT NULL, IdCard NVARCHAR(18) NOT NULL, -- 公安登记需要 Phone NVARCHAR(20), Sex TINYINT, -- 0男 1女 MemberLevel TINYINT DEFAULT 0, -- 0普通 1银卡 2金卡 CreateTime DATETIME DEFAULT GETDATE() ); -- 主订单表 CREATE TABLE MainOrder ( OrderId INT PRIMARY KEY IDENTITY(1,1), OrderNo NVARCHAR(32) NOT NULL, -- 业务单号，界面显示用 CustomerId INT NOT NULL REFERENCES Customer(CustomerId), OrderType TINYINT NOT NULL DEFAULT 0, -- 0散客 1协议客户 2网络渠道 Status TINYINT NOT NULL DEFAULT 0, -- 0待入住 1已入住 2已退房 3已取消 CheckInDate DATETIME NOT NULL, -- 计划入住时间 CheckOutDate DATETIME, -- 计划退房时间 ActualCheckOutDate DATETIME, -- 实际退房时间，结算凭证 Deposit DECIMAL(10,2) DEFAULT 0, -- 押金 TotalAmount DECIMAL(10,2) DEFAULT 0, -- 订单总金额 CreateTime DATETIME DEFAULT GETDATE() ); -- 订单明细表（如果是长包房、含餐、加床，按明细存） CREATE TABLE OrderItem ( ItemId INT PRIMARY KEY IDENTITY(1,1), OrderId INT NOT NULL REFERENCES MainOrder(OrderId), RoomId INT NOT NULL REFERENCES Room(RoomId), BeginDate DATETIME NOT NULL, EndDate DATETIME NOT NULL, PricePerDay DECIMAL(10,2) NOT NULL, Days INT NOT NULL, SubTotal DECIMAL(10,2) NOT NULL );

很多课程设计只有"订单表"没有"订单明细表"，这是一个隐患。一个客人订两间房，或一间房住五晚中间换了房型，一张订单一行数据就装不下了。拆出明细表之后，每个明细行对应"某房间某时段的入住"，主表只存客户信息和整体状态，账目清晰得多。

2.2 房间状态是"推倒出来"还是"存字段"

这个问题值得单独说。在房态展示页面上，你当然可以直接显示Room.Status。但有一个场景容易出问题：客人预订了三天后才入住的房间，这个房间当前状态是"空闲"，但未来某几天被占了。如果你只存Status一个字段，就没办法表达"今天空但周末已预订"的时空状态。

我采用的方案是：Room.Status只表达"此时此刻"的物理状态，用于前台当日房态图的快速展示；"未来某个日期段是否可预订"则通过查询订单明细，判断该房间在目标时间段是否有未取消的订单记录来推倒。这两者配合，前台既能看到当前房态大屏，也能支持预订时的日期范围查房。

-- 查某个房间在某时间段是否可用 SELECT COUNT(1) FROM OrderItem oi INNER JOIN MainOrder mo ON oi.OrderId = mo.OrderId WHERE oi.RoomId = @RoomId AND mo.Status IN (0, 1) -- 未取消且未退房 AND @StartDate < oi.EndDate AND @EndDate > oi.BeginDate;

这个区间查询是日期重叠判断的标准写法，能处理"入住时间落在已有订单范围内"的一切边界情况。实际开发时，我把它封装在DAL层，返回bool，业务层做判断。

2.3 价格计划：为什么不能把房价写死在Room表

再往后做一点就会遇到这个问题：同一间房，淡季380一晚，旺季680一晚，协议客户再打八折。如果房价只写在RoomType.BasePrice里，改价格就得改表，而且改完没记录，老板要查上周是什么价也查不到。

规范做法是增加一张价格计划表：

CREATE TABLE PricePlan ( PlanId INT PRIMARY KEY IDENTITY(1,1), TypeId INT NOT NULL REFERENCES RoomType(TypeId), StartDate DATE NOT NULL, EndDate DATE NOT NULL, Price DECIMAL(10,2) NOT NULL, IsHoliday TINYINT DEFAULT 0, -- 是否节假日价 Remark NVARCHAR(100) );

下单时取价的逻辑是：先按TypeId + 日期在PricePlan里找，找不到就回退到RoomType.BasePrice。用这个表之后，价格调整就是加一条记录的事，报表也能按时间段回算历史收入。

3. 三层架构的落地组织：从解决方案结构到代码分层

选型明确之后，怎么把代码组织起来就是最实际的工程问题。我在项目里用Visual Studio建解决方案，通常是四个项目：

HotelManage.sln ├── HotelManage.WebUI -- 表现层，aspx页面 ├── HotelManage.BLL -- 业务逻辑层 ├── HotelManage.DAL -- 数据访问层 └── HotelManage.Model -- 实体模型层（又额外抽出一个Model，是为了避免DAL和BLL互相引用没事干）

3.1 Model层：轻量实体还是DataSet

老项目里大量用DataSet/DataTable传数据，写起来确实快，GridView直接绑定就行。但一旦逻辑复杂，DataSet里没有类型约束，字段名写错是编译期发现不了的。我的做法是用POCO实体类，例如：

public class RoomInfo { public int RoomId { get; set; } public string RoomNo { get; set; } public int TypeId { get; set; } public string TypeName { get; set; } public int Floor { get; set; } public int Status { get; set; } public string StatusText { get; set; } }

DAL层返回List<RoomInfo>，BLL层拿到强类型数据做判断，UI层再绑定Repeater/GridView。多写几个属性，换来的是后续维护时，字段名拼错编译器直接报错，这种收益在项目后期非常明显。

3.2 DAL层：SqlHelper封装与参数化查询

DAL层最核心的是数据库访问封装的统一。我一般先写一个精简版SqlHelper，不需要引入完整的企业库，自己封装ExecuteNonQuery、ExecuteReader、ExecuteDataTable三个方法就够了，内部做好连接释放和事务支持。

一个容易犯的错误：在三层架构里，DAL的方法还一板一眼地写成"按主键查"、"查全部"。其实DAL方法应该面向业务需求命名。比如"查询某时间段可预订的房间"，DAL直接暴露SearchAvailableRooms(DateTime start, DateTime end, int typeId)，比暴露ExecuteDataTable("SELECT ...")更直观，也更好做单元测试。

所有SQL都建议走参数化查询，不要拼接字符串。这点怎么强调都不为过，尤其是像酒店系统这类要对接身份证、手机号的外部输入，一旦用户输入'; DROP TABLE Room; --，拼接SQL就直接炸了。

public List<RoomInfo> GetRoomsByStatus(int status) { string sql = @" SELECT r.RoomId, r.RoomNo, r.Floor, r.Status, rt.TypeName FROM Room r INNER JOIN RoomType rt ON r.TypeId = rt.TypeId WHERE r.Status = @Status ORDER BY r.RoomNo"; DataTable dt = SqlHelper.ExecuteDataTable(sql, new SqlParameter("@Status", status)); List<RoomInfo> list = new List<RoomInfo>(); foreach (DataRow row in dt.Rows) { list.Add(new RoomInfo { RoomId = Convert.ToInt32(row["RoomId"]), RoomNo = row["RoomNo"].ToString(), Floor = Convert.ToInt32(row["Floor"]), TypeName = row["TypeName"].ToString(), Status = Convert.ToInt32(row["Status"]) }); } return list; }

3.3 BLL层：业务规则到底放哪

BLL层最常见的失控是变成"透传层"——DAL返回什么，BLL就返回什么，所有判断都写在页面里。这是典型的三层变两层。

我在BLL层会坚持放这些规则：

• 预订：检查房间时间段是否可用；未满18岁不能单独入住（按证件号算年龄）；入住时间不能早于当前时间。
• 入住：订单状态必须是待入住；房间必须是空闲状态；押金必须大于等于第一晚房费。
• 退房：计算实住天数；超时退房要加收费用；有未结的餐饮消费要先挂账再结算。
• 换房：原房间释放，新房间占用，订单明细要拆成两段。

比如退房计费，这个规则如果写在页面Click事件里，换一个页面做"退房"功能你又得写一遍。写着写着就出现两套逻辑，账就对不上了。我建议把计费方法统一放BLL，返回一个SettlementResult对象，包含Days、RoomFee、OtherFee、DiscountAmount、TotalPayable等字段，UI层只负责展示。

3.4 Web.config连接字符串与发布坑

三层架构下，连接字符串一般放在Web.config的<connectionStrings>里。DAL层怎么拿到它？我的做法是SqlHelper内部读取ConfigurationManager.ConnectionStrings["HotelDB"].ConnectionString，但允许通过方法参数传入覆盖，方便写单元测试时指向测试库。

一个我踩过的坑：解决方案里多个项目，调试时DAL项目的App.config和Web项目的Web.config连接字符串不一致，结果本机跑得好好的，一到服务器上就报数据库连接失败。后来统一为DAL和BLL只认Web项目传过来的配置，不在DAL项目里另存连接字符串，这类问题才绝迹。

4. 核心功能模块的实现：预订、入住、退房、报表

下面把几个核心业务闭环完整走一遍，每一个我都给出实现思路和关键代码，你可以直接照着搭。

4.1 预订模块：可用房间查询与订单生成

预订页面基本流程是：选择入住时间、退房时间、房型 -> 查询可用房间 -> 选择具体房间 -> 填写客人信息 -> 生成订单。

查询可用房间的SQL在2.2给出过，实际使用时要再关联出房型和价格：

public List<RoomInfo> SearchAvailableRooms(DateTime start, DateTime end, int typeId) { string sql = @" SELECT r.RoomId, r.RoomNo, r.Floor, rt.TypeName, rt.BasePrice FROM Room r INNER JOIN RoomType rt ON r.TypeId = rt.TypeId WHERE r.Status = 0 AND rt.TypeId = @TypeId AND NOT EXISTS ( SELECT 1 FROM OrderItem oi INNER JOIN MainOrder mo ON oi.OrderId = mo.OrderId WHERE oi.RoomId = r.RoomId AND mo.Status IN (0, 1) AND @StartDate < oi.EndDate AND @EndDate > oi.BeginDate )"; }

下单时，除了插入MainOrder和OrderItem，还有一步很多人会忽略：把房间状态改成1（已预订）。如果不改，就会出现"预订了但房态图上还是空闲"，另一个前台人员不知道状况继续卖这间房。

订单号生成也有讲究。我见过用Guid当订单号显示给客人的，又长又难看；也见过直接用自增OrderId的，前台电话给客人报单号时太短容易被猜出业务量。我采用yyyyMMddHHmmss + 三位随机数的字符串，够长又具备时间可读性：

string orderNo = DateTime.Now.ToString("yyyyMMddHHmmss") + new Random().Next(100, 999).ToString();

4.2 入住登记：状态机一次转移到位

入住操作本质上是一次状态机转移：待入住 -> 已入住，房间从已预订变为已入住。但这里有个关键问题：客人预订后没来，房间已经释放为空闲了，这时能不能直接入住？理论上不行，因为状态机乱了。我处理的方式是想清楚状态机的全部合法迁移路径：

• 空闲 -> 已预订（下了预订订单）
• 已预订 -> 已入住（客人到店登记）
• 已预订 -> 空闲（预订取消）
• 已入住 -> 脏房（客人退房）
• 脏房 -> 空闲（保洁完成）

入住登记的事务逻辑：

public bool CheckIn(int orderId, int roomId) { // 1. 校验订单存在且状态为待入住 // 2. 校验房间状态为已预订（或空闲，针对无预订直接开房） // 3. 修改订单状态为已入住，记录实际入住时间 // 4. 修改房间状态为已入住 // 以上四步必须在同一个事务里，要么全成功要么全失败 }

事务是三层架构里BLL层最容易漏的部分。如果第3步成功、第4步失败，数据库里就是"订单已入住，房间还空着"，第二天房态图全乱。实现事务时，我用SqlHelper的重载版本，传入SqlConnection和SqlTransaction，让多个操作共享同一个事务上下文。

没有预订直接"无单开房"也是常见场景，这个流程是：创建订单（状态直接为已入住）+ 修改房间状态，同样包在事务里。

4.3 退房结算：按天还是按小时，超时怎么算

退房是收钱环节，算法必须严密。酒店通常以中午12点为界：第二天12点前退不算超时，12点后到18点退加收半天房费，18点后退加收一天房费。前台催人退房也是这个算法在驱动。

我在BLL里写一个费用计算：

public SettlementResult CalculateSettlement(MainOrder order) { DateTime checkIn = order.CheckInDate; DateTime checkOut = order.ActualCheckOutDate ?? DateTime.Now; TimeSpan span = checkOut - checkIn; int totalDays = (int)Math.Ceiling(span.TotalHours / 24.0); if (totalDays < 1) totalDays = 1; // 钟点房最少按一天算 // 超时部分按当天18点前/后两档 decimal roomFee = 0; // 主逻辑每天累加，最后一天单独按退房时间判断 for (int i = 0; i < totalDays; i++) { DateTime dayStart = checkIn.Date.AddDays(i); if (i == totalDays - 1 && checkOut.TimeOfDay > new TimeSpan(12, 0, 0)) { if (checkOut.TimeOfDay <= new TimeSpan(18, 0, 0)) roomFee += pricePerDay / 2; // 半天 else roomFee += pricePerDay; // 全天 } else { roomFee += pricePerDay; } } // 扣掉已付押金，得到应补金额 }

这个算法里的边界很多：凌晨入住算不算前一天？连住多天最后一天超时怎么算？长包房是否直接按月？我的建议是，BLL层把所有边界写成常量配置（比如计费截止时间12点、超时截止时间18点），放到配置里而不是硬编码，因为每家酒店的规则其实都不一样。做系统前先和业务方敲定规则，比开发完再改核算逻辑省心几十倍。

4.4 房态大屏与报表统计

房态大屏是酒店前台使用频率最高的页面，我一般按楼层分组展示房间卡片，不同颜色代表不同状态。查询逻辑很简单，就是GetRoomsByStatus，但要注意定时刷新：前台开着页面挂在大屏上，预订变化、入住变化都要能自动更新。老技术里用Timer定时回发或Meta Refresh都行，效果不重要，保障数据准确才重要。

报表部分最常被问到的指标是"出租率"。定义要明确：是卖出的间夜数除以可卖间夜总数，还是按房间数算？我的做法是明确算出"实际间夜数"——即某个时间段内所有订单占用的房间天数总和，再除以（房间总数 × 天数）。

-- 月度出租率 SELECT SUM(DATEDIFF(DAY, CASE WHEN BeginDate < @start THEN @start ELSE BeginDate END, CASE WHEN EndDate > @end THEN @end ELSE EndDate END)) AS OccupiedNights, (SELECT COUNT(1) FROM Room WHERE Status IN (0,1,2,3)) AS TotalRooms, DATEDIFF(DAY, @start, @end) AS Days FROM OrderItem oi INNER JOIN MainOrder mo ON oi.OrderId = mo.OrderId WHERE mo.Status = 2 AND mo.ActualCheckOutDate IS NOT NULL;

当然，这种报表写法适合课程设计和中小酒店，数据量大之后要按天生成统计表，避免实时全表扫描。但核心口径——"间夜数怎么算"——是一致的。

5. 开发中最容易踩的坑和排查思路

这个标题下，说几个我实际碰到过、而且网上一时半会查不到答案的问题。

5.1 并发问题：同一间房被两个人同时预订

模拟环境单用户测试根本发现不了这个问题。真正酒店前台有两台电脑，A接待员和B接待员同时操作，两个人同时看到1208房空闲，同时下单，Rabbit再快也躲不掉。

本质原因是"先查询再更新"的竞态条件。解决办法有两个层次：

第一层，在SQL层面做原子性防护。不要在BLL里SELECT + 判断 + UPDATE三步走，而是让UPDATE语句自带条件：

UPDATE Room SET Status = 1 WHERE RoomId = @RoomId AND Status = 0;

如果影响行数为0，说明房间已经被别人占用了，业务层直接返回"房间不可用"。

第二层，在事务中配合锁提示，比如用UPDLOCK：

SELECT 1 FROM Room WITH (UPDLOCK) WHERE RoomId = @RoomId AND Status = 0;

锁住该行直到事务结束，避免两个事务同时读到"空闲"。抢房场景在真实系统里一旦发生，轻则客人投诉订单重叠，重则酒店赔付。这个坑必须提前在架构上堵住。

5.2 日期时间边界：SQL和C#对日期的处理不一致

C#的DateTime精确到100纳秒，SQL Server的datetime精确到3.33毫秒，如果你用smalldatetime甚至只精确到分钟。存预订时间时还好，问题出在比较和分组：

• 查询"今天的预订"却用了WHERE CheckInDate = @today，结果一条都查不出来，因为存的是2025-06-01 14:00:00，等于的是2025-06-01 00:00:00。
• 按月汇总时直接GROUP BY DATEPART(month, CheckInDate)又忽略了跨年问题。

我的实用经验：日期筛选统一用半开区间>= 开始 AND < 次日；按月汇总时GROUP BY CONVERT(VARCHAR(7), CheckInDate, 120)，得到2025-06这种标准格式，跨年也不会混。如果表里数据量大，再考虑加一个纯日期字段或使用DATETRUNC做优化。

5.3 界面显示状态和实际状态不一致

这个问题通常不是代码bug，而是业务流程漏洞。比如操作员在"预订管理"里取消了订单，但只改了MainOrder.Status为3（取消），忘记把Room.Status从1（已预订）改回0（空闲）。之后前台看到房态图上1208一直处于"已预订"，实际上它早就是自由身了。

根治办法不是靠人记得，而是在BLL层把所有状态变更收敛成方法：CancelOrder方法内部保证"订单状态修改+房间状态恢复"在一个事务里执行。任何人想做取消操作，只能调这个封装好的方法，不允许直接改数据库。

5.4 老的GridView分页和ViewState臃肿

酒店管理系统的数据量通常不大，但房态日志、操作流水这类表时间长了也会增长。ASP.NET WebForms的GridView自带分页，默认EnableViewState="true"会把整个数据集序列化到隐藏字段里，几千条数据就能让页面变得很重。前台电脑配置不高，打开房态页转圈三秒，体验极差。

我给这类页面的建议：开EnableViewState="false"，自己实现分页查询，每次只取当前页的数据，SQL用OFFSET ... FETCH。如果没有历史包袱，现在做新系统我更推荐用ASP.NET Core + Razor Pages，性能问题从根上少很多。

6. 从这套老系统出发：现在重做会怎么选型

写到这里，我知道有一部分读者并不是在维护老代码，而是要新起一个酒店管理系统的课程设计或公司内部项目。如果今天从头做，我有一些基于实践的判断。

6.1 技术栈：还坚持WebForms吗

如果题目限定ASP.NET WebForms，那上面所有内容都适用。但如果是全新项目，没有再被旧代码绑住，我更倾向ASP.NET Core + Razor Pages或MVC + EF Core。核心原因是：

• 跨平台部署方便，Linux上跑容器很成熟。
• 内置依赖注入，三层架构的层间解耦更容易实现。
• 自带异步支持，前台并发操作下的体验更好。

但注意一点：不管是WebForms还是Core，三层架构的思想照样适用。换的是表现层的壳，BLL和DAL的职责划分逻辑完全一致。我见过不少人跳到Core之后，又写出一堆Controller里直接db.Room.ToList()的代码，那是把三层架构丢了，不是技术的错。

6.2 ORM还是手写SQL

EF Core这类ORM能极大提高开发效率，尤其是Room、Order、Customer这种标准CRUD。但报表类查询、复杂联表、促销价格计算，用EF写起来要么生成低效SQL，要么可读性很差。我的组合是：CRUD用ORM，复杂统计SQL封装成存储过程或直接在DAL写SqlQuery执行。账目、结算这类涉及钱的逻辑，我坚持用可以审查的SQL，不依赖黑盒生成。

6.3 这个系统的扩展方向

按我的经验，一套稳定的酒店管理系统做完核心业务之后，最值得扩展的并不是更多花哨页面，而是：

• 对接身份证读卡器，入住登记时自动读取证件信息，减少前台录入时间。
• 对接门锁系统，客房入住后自动授权房卡。
• 对接公众号小程序，让客人自助选房、自助退房。
• 增加多渠道订单同步，OTA平台的订单自动导入到系统。

这些扩展都在验证一个事：当初建的表结构是否支持外部数据对接。比如订单表里是否预留ChannelOrderNo、ChannelSource字段，客人表有没有ExternalId。如果一开始没留，后面接OTA订单的时候，就得在表上做各种奇怪的兼容，麻烦得很。

我现在做一个酒店管理系统开发时，有一个习惯：任何状态值都不直接写数字在代码里，统一用枚举或常量类，比如RoomStatus.Free、RoomStatus.Occupied。前期多写几行定义，后期别人接手时看代码不用猜Status=2到底是什么，这个习惯帮我省了无数解释成本。如果你今天准备开始写这个系统，我建议你也从枚举和事务这两件事抓起——状态清晰，账目一致，这套系统的骨架就稳了一大半。