C# WinForms宿舍管理系统：三层架构与SQL Server/SQLite实战

简介：这是一套面向C#初学者与课程设计需求的宿舍信息管理系统源码，基于WinForm界面、SQL Server数据库与三层架构（BLL/DAL/Models）组织，适合用来学习分层开发思想与数据库增删查改的完整实现。压缩包共126个文件，约495KB，其中43个cs源码文件构成各层核心逻辑，另有9个resx与9个resources资源文件、4个csproj工程文件、2个config配置及若干dll、pdb、cache等编译与调试产物，结构完整可直接用Visual Studio打开运行。系统覆盖管理员登录注册、账号信息修改，以及学生宿舍信息的添加、删除、精确或模糊查询与修改等基本功能，能帮助读者理解实体层、数据访问层与业务逻辑层之间的调用关系，并掌握WinForm控件与SQL Server的配合方式。目前已有155人学习，适合作为课程设计参考或三层架构入门练手项目。

1. 从一次宿舍调宿说起：三层架构到底解决了什么

每年开学季，宿管中心最头疼的不是床位不够，而是调宿。一个学生从 3 号楼 412 换到 5 号楼 208，背后要动的东西比想象中多：床位状态要改、原宿舍人数要减、新宿舍人数要加、住宿费差额要重算、门禁名单要同步。如果这些逻辑全塞在一个按钮的点击事件里，改一次需求就得把整个窗体代码翻一遍，这就是典型的“能跑但不敢动”。

C# Windows 基于三层架构的宿舍信息管理系统，本质上是把这类业务拆成三份职责：界面只负责收集和展示，业务规则集中在一层里判断，数据库读写再单独隔开。它适合两类人：一类是刚学完 C# 基础、想找一个能写进简历又不至于烂大街的课程设计；另一类是在学校或小园区做后勤信息化的开发者，需要一个能长期维护、后续能加报表和权限的底子。数据库选 SQL Server 还是 SQLite，取决于你是单机演示还是多机共用，这个后面会细说。

三层架构不是银弹，它带来的是“改一处不影响全局”的可维护性，代价是文件数量变多、调用链变长。对宿舍管理这种实体关系清晰、增删改查密集、后期一定会加需求的场景，这笔账是划算的。

2. 三层架构的边界怎么划：别把业务逻辑写进按钮里

2.1 三层各自的职责与依赖方向

三层架构的经典划分是表示层（UI）、业务逻辑层（BLL）、数据访问层（DAL），再加上一个贯穿三层的实体模型（Model）。依赖方向必须是 UI 调 BLL、BLL 调 DAL，DAL 只认数据库，绝不反向引用。很多人的翻车点在于：UI 里直接new SqlConnection，或者 BLL 里写 SQL 字符串，这样三层就退化成了“三层文件夹”，没有任何解耦价值。

表示层负责窗体的加载、控件事件响应、输入格式的初步校验（比如学号不能为空），但它不应该判断“这个床位是否已被占用”——那是业务规则。业务逻辑层负责调宿合法性、床位容量上限、重复入住检测、费用计算，它接收 UI 传来的简单参数，返回结果或抛出自定义异常。数据访问层负责参数化 SQL、事务、连接管理，它不知道“调宿”是什么业务，只知道“更新床位表某行状态”。

实体模型是三层之间传递数据的载体。宿舍场景里常见的实体有：学生（Student）、宿舍楼（Building）、房间（Room）、床位（Bed）、入住记录（CheckInRecord）、管理员（Admin）。每个实体类的属性要和数据库字段对应，但不要直接把 DataTable 当实体传，那样业务层就没法做类型安全的判断。

2.2 用接口隔离 DAL，方便换数据库

如果一开始就把 DAL 写成具体类，后面想从 SQL Server 换到 SQLite 演示，就得改 BLL 的调用代码。常见做法是给每个数据访问类抽一个接口，比如IStudentDAL，BLL 只依赖接口，具体实现通过简单工厂或依赖注入创建。下面是一个最小可用的接口和实现示例。

// DAL/IStudentDAL.cs —— 只声明契约，不涉及任何数据库细节 public interface IStudentDAL { int Insert(Student student); // 返回新生成的自增主键 bool Update(Student student); bool Delete(string studentNo); // 按学号删除，学号是业务主键 Student GetByNo(string studentNo); List<Student> GetAll(); } // DAL/SqlServerStudentDAL.cs —— SQL Server 实现 public class SqlServerStudentDAL : IStudentDAL { private readonly string _connStr; public SqlServerStudentDAL(string connStr) { _connStr = connStr; } public int Insert(Student student) { // 参数化 SQL，杜绝拼接字符串带来的注入风险 const string sql = @"INSERT INTO Student(StudentNo, Name, Gender, ClassName, Phone) VALUES(@No, @Name, @Gender, @Class, @Phone); SELECT SCOPE_IDENTITY();"; using (var conn = new SqlConnection(_connStr)) using (var cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@No", student.StudentNo); cmd.Parameters.AddWithValue("@Name", student.Name); cmd.Parameters.AddWithValue("@Gender", student.Gender); cmd.Parameters.AddWithValue("@Class", student.ClassName); cmd.Parameters.AddWithValue("@Phone", student.Phone ?? (object)DBNull.Value); conn.Open(); return Convert.ToInt32(cmd.ExecuteScalar()); } } // 其余方法省略，结构一致 }

这段代码的关键点有三个。第一，接口只暴露业务语义方法，不暴露ExecuteNonQuery这类通用方法，否则 BLL 又会绕过接口写 SQL。第二，SCOPE_IDENTITY()取当前作用域的自增 ID，比@@IDENTITY安全，后者在有触发器时会取错。第三，Phone允许为空时用DBNull.Value，直接传null会抛参数异常，这是新手最常见的报错之一。

参数说明：_connStr从配置文件读取，不要硬编码在类里；AddWithValue虽然方便，但对decimal类型可能推断成float导致精度问题，费用字段建议显式指定SqlDbType.Decimal。

2.3 业务层的一个真实规则：调宿时的事务边界

调宿是典型的跨表操作，必须放在一个事务里。BLL 负责编排，DAL 负责执行，事务对象由 DAL 提供或通过TransactionScope包裹。下面演示 BLL 如何调用两个 DAL 方法完成调宿。

// BLL/CheckInBLL.cs —— 调宿业务，先校验再落库 public class CheckInBLL { private readonly IBedDAL _bedDal; private readonly ICheckInDAL _checkInDal; public CheckInBLL(IBedDAL bedDal, ICheckInDAL checkInDal) { _bedDal = bedDal; _checkInDal = checkInDal; } public void TransferBed(string studentNo, int newBedId) { // 1. 业务校验：新床位必须存在且空闲 var newBed = _bedDal.GetById(newBedId); if (newBed == null) throw new BizException("目标床位不存在"); if (newBed.Status != BedStatus.Free) throw new BizException("目标床位已被占用"); // 2. 释放旧床位、占用新床位、写调宿记录，三步必须同成败 using (var scope = new TransactionScope()) { _bedDal.ReleaseByStudent(studentNo); // 旧床位置为空闲 _bedDal.Occupy(newBedId, studentNo); // 新床位置为占用 _checkInDal.InsertTransfer(studentNo, newBedId, DateTime.Now); scope.Complete(); // 不调用则自动回滚 } } }

逻辑说明：校验放在事务外，是为了尽早失败、减少锁持有时间；真正的写操作放在TransactionScope内，任何一步抛异常，Complete()不执行，事务自动回滚。参数上，studentNo用学号而不是自增 ID，是因为学号在业务上唯一且稳定，调宿时 UI 传的就是学号。注意TransactionScope默认隔离级别是Serializable，并发高时容易死锁，宿舍系统并发低可以接受，若以后要优化可显式指定ReadCommitted。

3. 数据库表设计与 SQL Server / SQLite 的选型

3.1 核心表结构与字段约束

宿舍管理的数据关系不复杂，但约束要提前想清楚，否则后期数据一乱就得写脚本清洗。下面给出核心表的设计要点，字段类型以 SQL Server 为准，SQLite 对应调整即可。

Bed表的Status和StudentNo要联动：占用时StudentNo必须有值，空闲时必须为空。这个约束用触发器或业务层保证都行，但业务层更可控，因为触发器报错信息对用户不友好。Room.Capacity和该房间下Bed的数量要一致，插入床位时校验，避免出现“容量 4 人却放了 6 张床”的脏数据。

3.2 SQL Server 与 SQLite 的取舍

单机课程设计、演示环境，SQLite 足够：一个.db文件，免安装，拷贝即用，System.Data.SQLite或Microsoft.Data.Sqlite都能接。但 SQLite 不支持高并发写，多人同时调宿会锁库，且没有内置的用户权限体系。如果系统要部署在宿管中心几台电脑上共用，选 SQL Server Express 版，免费且支持网络访问和账号权限。

切换数据库时，DAL 层换实现类即可，BLL 和 UI 不动。连接字符串放App.config的connectionStrings节点，不要写死在代码里。SQLite 的连接字符串形如Data Source=dorm.db;Version=3;，SQL Server 则是Server=.;Database=DormDB;Integrated Security=True;。注意 SQLite 没有SCOPE_IDENTITY()，取自增 ID 用last_insert_rowid()，这是换库时最容易漏改的地方。

3.3 建表脚本与初始化数据

下面是一段可直接执行的 SQL Server 建表脚本，包含主外键和默认值。

-- 宿舍楼表 CREATE TABLE Building ( BuildingId INT IDENTITY(1,1) PRIMARY KEY, BuildingName NVARCHAR(50) NOT NULL UNIQUE, GenderLimit CHAR(1) NOT NULL CHECK (GenderLimit IN ('M','F')) ); -- 房间表，外键指向宿舍楼 CREATE TABLE Room ( RoomId INT IDENTITY(1,1) PRIMARY KEY, BuildingId INT NOT NULL FOREIGN KEY REFERENCES Building(BuildingId), RoomNo NVARCHAR(10) NOT NULL, Capacity INT NOT NULL DEFAULT 4 CHECK (Capacity BETWEEN 1 AND 8), CONSTRAINT UQ_Room UNIQUE (BuildingId, RoomNo) ); -- 床位表，Status 用约束限定取值 CREATE TABLE Bed ( BedId INT IDENTITY(1,1) PRIMARY KEY, RoomId INT NOT NULL FOREIGN KEY REFERENCES Room(RoomId), BedNo INT NOT NULL, Status VARCHAR(10) NOT NULL DEFAULT 'Free' CHECK (Status IN ('Free','Occupied')), StudentNo VARCHAR(20) NULL, CONSTRAINT UQ_Bed UNIQUE (RoomId, BedNo) );

逻辑说明：IDENTITY(1,1)是 SQL Server 自增写法，SQLite 用INTEGER PRIMARY KEY AUTOINCREMENT。UNIQUE约束防止同一房间出现重复房号、同一房间出现重复床号，这类脏数据一旦产生，后续按房号查询会返回多条，排查起来很费时间。CHECK约束把Status和GenderLimit的取值锁死，比在代码里到处判断要可靠。初始化数据建议单独写一个seed.sql，插入几栋楼、若干房间和床位，方便第一次运行时就有数据可测。

4. 从登录到调宿：WinForms 界面与三层的对接

4.1 登录窗体的最小实现

登录是三层对接的第一个完整链路：UI 收集账号密码，BLL 校验，DAL 查库。下面给出登录按钮的核心代码。

// UI/LoginForm.cs —— 登录按钮事件 private void btnLogin_Click(object sender, EventArgs e) { string user = txtUser.Text.Trim(); string pwd = txtPwd.Text.Trim(); if (string.IsNullOrEmpty(user) || string.IsNullOrEmpty(pwd)) { MessageBox.Show("账号和密码不能为空"); return; } try { var bll = new AdminBLL(new SqlServerAdminDAL(Config.ConnStr)); Admin admin = bll.Login(user, pwd); // 失败抛 BizException if (admin == null) { MessageBox.Show("账号或密码错误"); return; } this.Hide(); new MainForm(admin).ShowDialog(); // 把当前管理员传给主窗体 this.Close(); } catch (BizException ex) { MessageBox.Show(ex.Message); // 业务异常直接展示给用户 } catch (Exception ex) { MessageBox.Show("系统异常，请联系管理员"); LogHelper.Write(ex); // 技术异常写日志，不暴露细节 } }

逻辑说明：UI 只做非空校验，密码比对在 BLL 里做（实际项目应存哈希值，课程设计可先存明文再升级）。BizException是自定义业务异常，用来区分“用户能看懂的错”和“用户看不懂的错”。参数上，Trim()去掉输入框首尾空格，避免用户复制粘贴时带入空格导致登录失败，这个坑非常隐蔽。MainForm构造函数接收Admin对象，后续做权限控制时直接读它的角色字段。

4.2 学生信息增删改查的界面绑定

学生管理界面通常用DataGridView展示列表，配合增删改按钮。关键点是：不要直接把DataTable绑上去就完事，选中行时要能拿到对应的实体。下面演示加载和删除。

// UI/StudentForm.cs —— 加载列表与删除选中行 private void LoadStudents() { var bll = new StudentBLL(new SqlServerStudentDAL(Config.ConnStr)); dgvStudents.AutoGenerateColumns = false; // 手动定义列，避免显示全部字段 dgvStudents.DataSource = bll.GetAll(); } private void btnDelete_Click(object sender, EventArgs e) { if (dgvStudents.CurrentRow == null) return; string no = dgvStudents.CurrentRow.Cells["colStudentNo"].Value.ToString(); if (MessageBox.Show($"确认删除学号 {no} 的学生？", "提示", MessageBoxButtons.YesNo) != DialogResult.Yes) return; try { new StudentBLL(new SqlServerStudentDAL(Config.ConnStr)).Delete(no); LoadStudents(); // 删除后刷新，保持界面与库一致 } catch (BizException ex) { MessageBox.Show(ex.Message); // 例如“该学生有在住记录，不能删除” } }

逻辑说明：AutoGenerateColumns = false后手动加列，列名与实体属性对应，避免把数据库所有字段暴露在界面上。删除前先查该学生是否有未退宿记录，有则抛业务异常，这是 BLL 的职责，UI 不判断。参数上，CurrentRow.Cells["colStudentNo"]里的列名要和设计器里设的Name一致，改名后忘记同步是常见翻车点。删除后必须重新加载，否则界面还显示已删数据，用户会以为没删掉。

4.3 调宿界面的交互与刷新

调宿界面一般左边显示当前学生信息，右边显示可选空闲床位。用户选中新床位点确认，调 BLL 的TransferBed。成功后要同时刷新床位列表和学生信息，因为两边都变了。这里有个细节：调宿过程中如果目标床位被另一个人抢先占用，BLL 会抛“目标床位已被占用”，UI 捕获后提示并刷新床位列表，让用户重新选。这个并发场景在单机演示里遇不到，但多机共用时一定会出现，提前处理能省很多麻烦。

5. 避坑与排查：那些让系统跑不起来的细节

5.1 连接字符串写错导致“登录失败”

现象：程序一启动就报“用户 ‘sa’ 登录失败”或“无法打开登录所请求的数据库”。原因通常是连接字符串里的服务器名、实例名或认证方式不对。SQL Server Express 默认实例名是.\SQLEXPRESS，不是.。解决：先用 SSMS 用同样的账号密码连一次，确认能连上，再把 SSMS 里的服务器名原样抄进连接字符串。用 Windows 身份验证时写Integrated Security=True，不要同时写用户名密码。

5.2 参数化 SQL 里传 null 抛异常

现象：新增学生时不填电话，点保存报“参数化查询需要参数 @Phone，但未提供该参数”。原因是AddWithValue("@Phone", null)传的是 C# 的null，ADO.NET 不认。解决：统一写成student.Phone ?? (object)DBNull.Value，或者封装一个ToDbValue扩展方法。这个坑在可空字段多的表上会反复出现，建议在 DAL 基类里统一处理。

5.3 DataGridView 绑定后修改不生效

现象：在界面上改了学生姓名，点保存后数据库没变。原因是直接绑定了List<Student>，DataGridView的修改只改内存对象，不会回写。解决：要么用BindingList<Student>并实现INotifyPropertyChanged，要么放弃直接绑定，改成“选中行填充到下方编辑框，改完点保存再调 BLL 更新”。课程设计推荐后者，逻辑清晰，不容易出玄学问题。

5.4 事务未提交导致数据“消失”

现象：调宿后查询，旧床位释放了但新床位没占用，数据处于中间状态。原因是TransactionScope里某一步抛异常被吞掉，或者忘记调scope.Complete()。解决：确保Complete()在 try 块最后一行，异常直接向上抛，不要在里面catch后不处理。另外TransactionScope要using包裹，否则连接不释放，后续操作会超时。

5.5 发布到其他电脑后连不上数据库

现象：本机跑得好好的，拷到室友电脑上就报数据库连接错误。原因是连接字符串里写的是localhost或本机实例名，目标机器上没有对应实例，或者没装 SQL Server。解决：演示场景直接换 SQLite，把.db文件随程序一起拷过去，连接字符串改成相对路径Data Source=|DataDirectory|\dorm.db;，并在程序启动时设置AppDomain.CurrentDomain.SetData("DataDirectory", Application.StartupPath)。这样换机器零配置，答辩时最稳。

6. 让这套系统更耐用的两个进阶习惯

第一个习惯是给所有数据库操作加一层薄薄的日志。不用上 log4net 这种重家伙，一个静态类往文本文件追加时间、SQL 摘要、影响行数就够了。宿舍系统出问题时，用户只会说“保存没反应”，有了日志你能直接看到是 SQL 报错还是影响行数为 0，排查时间从半小时降到两分钟。日志文件按天切分，超过 30 天自动删，避免占满磁盘。

第二个习惯是把“查询条件”和“分页”提前设计进 DAL。现在学生表可能只有几百行，GetAll()没问题，但宿舍系统用几年后数据量上来，全表加载会明显卡顿。DAL 接口里预留GetByPage(int pageIndex, int pageSize, string keyword)，SQL Server 用OFFSET ... FETCH NEXT，SQLite 用LIMIT ... OFFSET。UI 上加一个搜索框和上一页下一页按钮，改动不大，但系统立刻显得专业很多。

验证方法很简单：造 5000 条学生数据，分别用GetAll()和分页方法加载，用Stopwatch计时，差距通常在 10 倍以上。这个实测数据写进课程设计报告，比任何文字描述都有说服力。

我自己做这类系统最大的教训是：一开始总想先把界面画漂亮，结果业务逻辑散落在各个按钮里，加到第五个功能就改不动了。后来强迫自己先写实体和 DAL 接口，再写 BLL，最后才拖控件，返工次数明显下降。三层架构的价值不在代码量，而在你改需求时敢不敢直接动那一层。希望帮到你。

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