简介外聘教师管理系统是一套面向学校教务与人事管理场景的C# WinForms课程设计/小型管理系统源码采用SQL Server数据库围绕外聘教师信息维护、按院系/课程/姓名查询与统计、按代课数量和代课金级别计算工资、系部课程及代课金级别维护、登录权限与改密等模块展开适合学习桌面端CRUD、统计查询和权限控制的学生与开发者参考。压缩包共97个文件约35.47MB包含26个cs源码、25张界面截图、多组resx/resources资源、dll与exe运行文件以及mdf/ldf数据库、sln/csproj工程和配置文件目录覆盖窗体设计、业务逻辑与数据库部分。已有437人学习下载可用于对照完整工程理解窗体跳转、查询统计和普通用户只读权限的实现包内附SQL2012数据库修改数据库连接后即可运行调试。1. 外聘教师管理系统一份课酬表从 Excel 搬进 C# 加 SQL 的全过程每到学期末教务办最头疼的事情不是排课而是核算外聘老师的课酬课时数记录在教务系统的导出表里职称系数保存在一张随手更新的 Excel 中跨校区上课的补贴又记在另一个文档中三份数据反复核对一遍通常要花两天时间一旦中间改了一门课就得从头再算一遍。这套外聘教师管理系统就是把这套流程固化下来——用 C# WinForms 做录入和结算界面用 SQL Server 存放教师档案、授课任务和结算单点击“生成结算”后直接生成一张可以打印的课酬表。它适合三类人看做课程设计或毕设、需要一套完整三层架构范例的在校开发者需要给二级学院做小型内网工具的独立开发者以及接手了这类历史项目、要在一堆DataGridView里加字段的维护者。下面按照我拆解项目的顺序展开从解压后先看哪里到核心的课酬计算怎样才算对再到如何改成可配置规则。2. 技术选型与目录结构WinForms 加 ADO.NET 三层怎么落地2.1 为什么是 C# WinForms SQL Server而不是 Web先说结论这套系统的使用场景是内网办公用户数一只手数得过来数据量在万级以内所以选用 WinForms 不是技术保守而是把维护成本压到最低。教务办只有两三台电脑一台装数据库其余装客户端双击 exe 就能用不需要 IIS不需要域名也不用担心浏览器版本兼容。DataGridView这种控件天生适合“一行一个老师、一列一个字段”的录入场景改一个单元格就能修改比 Web 表单提交后还要刷新页面方便得多。数据库选 SQL Server 也是同一个思路外聘教师、授课任务、结算单之间存在明确的主外键关系用视图和存储过程把“按学期汇总课酬”这个动作下沉到数据库客户端只负责展示结果。如果换成 SQLite部署是更省事但多台机器共享同一份数据时就会很麻烦换成 MySQL 也能运行只是这套代码里大量使用SqlParameter、SqlDataAdapter迁移要修改的访问层代码不少没必要。代价也要说清楚避免使用后才发现问题。WinForms 的界面风格比较陈旧高分屏缩放下控件会模糊需要在app.manifest里开启 DPI 感知客户端更新时需要把新的 exe 拷贝过去后续可以考虑 ClickOnce并发能力很弱两个人同时点击“结算”是唯一的真实并发点这一点在第 5 章的避坑里还会遇到。放到这个项目上这些代价都可以接受但如果以后要支持外聘教师自己登录查询课酬就应当切换到 Web不应强行修改 WinForms。2.2 从 .rar 解压后先看这四个目录解压之后不要急着双击 sln 运行——先看清楚分层修改代码时才知道该在哪里改。按照这个项目场景合格开发一般会拆成 Model / DAL / BLL / UI 四层加一个独立的数据库脚本目录。我把它整理成表格方便对照路径职责修改频率ETMS.sln解决方案入口一般包含 4 个项目低DB/ETMS.sql建库建表、视图、存储过程、初始字典数据中加字段必改Model/实体类如Teacher、TeachingTask、Settlement中DAL/DbHelper 各表的XxxDAL只写 SQL 和参数高BLL/业务规则课酬计算、学期状态校验都在这一层高UI/窗体FrmTeacher、FrmSettle、FrmMain高App.config连接字符串、日志开关部署时改四个项目的引用关系是单向的UI 引用 BLLBLL 引用 DAL 和 ModelDAL 引用 ModelModel 谁都不引用。这条引用必须遵守——我见过不少同类项目图省事在窗体里直接new SqlConnection连接数据库结果连接字符串散落在二十多个文件里换一台机器部署时要全局搜索并替换那才是真正的麻烦。判断一个 WinForms 项目分层是否清晰有一个很快的检查方法打开任意一个.cs窗体文件搜索SqlConnection。如果搜到了说明它正在绕过 BLL 直接访问数据库这个项目的可维护性就要打折扣如果整个 UI 目录一个都搜不到说明分层是干净的后续加字段只需要改 DAL 和 BLL。2.3 连接字符串与 App.config 的正确写法部署时最容易出问题的就是这一步。序里写死的连接字符串在新机器上一定会失败所以要统一放到App.config的connectionStrings节点里代码只按名字读取?xml version1.0 encodingutf-8? configuration connectionStrings !-- Data Source 用 机器名\实例名本机默认实例可写 . 或 (local) -- add nameETMS connectionStringData Source.;Initial CatalogETMS;User IDetms_user;Password******;Connect Timeout15 providerNameSystem.Data.SqlClient / /connectionStrings appSettings !-- 结算时是否允许跨学期重算默认关闭防止误操作改历史账 -- add keyAllowResettle valuefalse / /appSettings /configuration读取的时候包一层避免配置缺失时抛出的异常让人摸不着头脑// DAL/DbConfig.cs public static class DbConfig { private static string _conn; public static string Conn { get { if (_conn null) { var setting ConfigurationManager.ConnectionStrings[ETMS]; if (setting null) throw new ConfigurationErrorsException(App.config 中缺少名为 ETMS 的连接字符串); _conn setting.ConnectionString; } return _conn; } } // 单元测试或临时切库时用正式运行不会走这里 public static void Override(string conn) { _conn conn; } }参数里几个点要交代清楚。Data Source.表示本机默认实例如果安装的是命名实例比如装了 Express 版必须写成.\SQLEXPRESSInitial Catalog是库名改名了这里要同步修改Connect Timeout15是连接超时默认也是 15 秒显式写出来是为了让运维看到认证方式建议用 SQL 账号而不是 Windows 集成认证因为教务办的机器不一定会加入域Integrated SecurityTrue在跨机器调用时反而会变成新的麻烦。AllowResettle这个开关在后续结算逻辑里会用到用来防止历史学期被重复计算。3. 数据库设计教师、授课任务、结算单三张主表怎么串3.1 建表脚本与字段设计整个系统的数据模型其实是一条链一个教师在一个学期里承担若干门课的授课任务学期结束时把所有任务按职称系数折算成课酬写进结算单。所以核心是五张表加两张字典表。我把关键部分的建表语句贴出来字段类型是血泪经验调过的-- 职称字典系数决定课酬倍率放在表里而不是写死在代码里 CREATE TABLE Title ( TitleId INT IDENTITY(1,1) PRIMARY KEY, TitleName NVARCHAR(20) NOT NULL, -- 助教/讲师/副教授/教授 Coefficient DECIMAL(4,2) NOT NULL, -- 1.00 / 1.20 / 1.50 / 1.80 IsActive BIT NOT NULL DEFAULT(1) ); CREATE TABLE Teacher ( TeacherId INT IDENTITY(1,1) PRIMARY KEY, TeacherNo VARCHAR(20) NOT NULL, -- 工号唯一纯 ASCII 用 varchar TeacherName NVARCHAR(30) NOT NULL, -- 姓名必须 nvarchar否则生僻字乱码 TitleId INT NOT NULL, DeptName NVARCHAR(50) NULL, -- 外聘教师可能不属于任何院系 Phone VARCHAR(20) NULL, BankAccount VARCHAR(32) NULL, Status TINYINT NOT NULL DEFAULT(1), -- 1 在职 0 停用 CreateTime DATETIME NOT NULL DEFAULT(GETDATE()), CONSTRAINT UQ_Teacher_No UNIQUE (TeacherNo), CONSTRAINT FK_Teacher_Title FOREIGN KEY (TitleId) REFERENCES Title(TitleId) ); -- 授课任务一门课一个外聘老师一条同一老师同一课程可多条不同班级 CREATE TABLE TeachingTask ( TaskId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, TeacherId INT NOT NULL, CourseName NVARCHAR(60) NOT NULL, ClassName NVARCHAR(60) NULL, Campus NVARCHAR(20) NULL, -- 校区跨校区有补贴 Hours DECIMAL(6,1) NOT NULL, -- 允许 0.5 学时 StudentCount INT NULL, CONSTRAINT FK_Task_Teacher FOREIGN KEY (TeacherId) REFERENCES Teacher(TeacherId) ); -- 结算单一个学期一个老师一条TotalAmount 是最终发放金额 CREATE TABLE Settlement ( SettleId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, TeacherId INT NOT NULL, TotalHours DECIMAL(8,1) NOT NULL, TotalAmount DECIMAL(12,2) NOT NULL, Status TINYINT NOT NULL DEFAULT(0), -- 0 草稿 1 已确认 Operator NVARCHAR(30) NULL, CreateTime DATETIME NOT NULL DEFAULT(GETDATE()), CONSTRAINT UQ_Settle UNIQUE (TermId, TeacherId) -- 唯一约束是幂等的最后一道锁 );这段脚本里有三个决定必须说明。第一TeacherName用NVARCHAR而TeacherNo用VARCHAR这是有意的工号是数字和字母varchar节省空间且索引更小姓名里会出现生僻字varchar在非 Unicode 排序规则下直接存成问号那就是数据事故。第二Hours用DECIMAL(6,1)而不是INT教务这边确实存在 1.5 学时、0.5 学时的情况用整数会出现“明明 24 学时算出来 23”的玄学问题。第三UQ_Settle这个唯一约束看起来可有可无实际上是并发重复结算的最后一道防线第 5 章会展开讲它为什么比代码里的if判断更可靠。3.2 视图与存储过程把课酬汇总下沉到数据库课酬的计算口径是课时 × 职称系数 × 单位课时费 跨校区补贴。这个公式一旦写死在 C# 里每次调整口径都要重新编译发版放到存储过程里只改脚本就行。我先建一个明细视图把任务、教师、职称串起来CREATE VIEW vw_TaskDetail AS SELECT t.TaskId, t.TermId, t.TeacherId, te.TeacherNo, te.TeacherName, ti.TitleName, ti.Coefficient, t.CourseName, t.ClassName, t.Campus, t.Hours, -- 跨校区补贴按每学时固定 10 元放到配置表更好这里先内联 CASE WHEN t.Campus IS NOT NULL AND t.Campus N主校区 THEN 10.00 ELSE 0.00 END AS CampusSubsidy FROM TeachingTask t JOIN Teacher te ON te.TeacherId t.TeacherId JOIN Title ti ON ti.TitleId te.TitleId;结算存储过程我一般写成“先清理草稿再重算”保证多次执行的最终结果一致CREATE PROCEDURE usp_CalcSettlement TermId INT, Operator NVARCHAR(30) AS BEGIN SET NOCOUNT ON; BEGIN TRY BEGIN TRAN; -- 1. 已确认的单据不允许重算直接抛出业务错误 IF EXISTS (SELECT 1 FROM Settlement WHERE TermId TermId AND Status 1) BEGIN RAISERROR(N该学期已有确认的结算单请先反确认, 16, 1); END -- 2. 清掉旧草稿实现幂等 DELETE FROM Settlement WHERE TermId TermId AND Status 0; -- 3. 按教师汇总用 ROUND 显式指定四舍五入方式 INSERT INTO Settlement (TermId, TeacherId, TotalHours, TotalAmount, Status, Operator) SELECT TermId, d.TeacherId, SUM(d.Hours), SUM(ROUND(d.Hours * d.Coefficient * 100.0, 2) d.CampusSubsidy * d.Hours), 0, Operator FROM vw_TaskDetail d WHERE d.TermId TermId GROUP BY d.TeacherId; COMMIT; END TRY BEGIN CATCH IF TRANCOUNT 0 ROLLBACK; THROW; -- 把原始错误抛给上层不要在存储过程里吞掉 END CATCH END逐段看TermId是学期主键UI 上选哪一学期就传哪个Operator记录操作人出问题时能追到是谁点击的。第 1 步的RAISERROR用的是THROW之外的业务报错方式16表示可以捕获的用户级错误。第 3 步的SUM(ROUND(...))是先按单条任务四舍五入再汇总而不是汇总完再四舍五入这两种算法在 3 条以上任务时会差出几分钱财务那边对不上账的根源往往就在这里。100.0是单位课时费实际部署时应当从配置表读取我这里是简化版。THROW而不吞异常这一点值得单独说。很多同类的存储过程在CATCH里只写SELECT ERROR_MESSAGE()然后RETURN调用方拿到的是“执行成功但没数据”排查时完全是黑匣子。用THROW把原始错误码和消息抛回 ADO.NETC# 侧catch (SqlException ex)能直接拿到错误号和文本定位快得多。3.3 索引与数据量预估别等到卡了才加这套系统的真实数据量大概是教师几百条每学期授课任务两三千条结算单几百条。这个量级下全表扫描也不会明显卡顿但该建的索引还是要建因为它的成本几乎为零-- 结算时按学期 教师聚合这个是覆盖面最广的 CREATE NONCLUSTERED INDEX IX_Task_Term_Teacher ON TeachingTask (TermId, TeacherId) INCLUDE (Hours, Campus); -- 教师列表按状态筛选 按工号排序 CREATE NONCLUSTERED INDEX IX_Teacher_Status_No ON Teacher (Status, TeacherNo);INCLUDE里放Hours和Campus是为了让结算查询走覆盖索引不用回表。这个技巧在几千行数据上感知不到但如果哪天有院系把历史五年的数据一起导进来就是能不能接受的区别。字段类型上还有两个常见误用要提醒金额一律DECIMAL(12,2)不要用MONEYMONEY在参与复杂表达式时精度行为不直观而且各家数据库迁移时不兼容日期用DATETIME2比DATETIME精度更高但这个项目里全是“某年某月某日”的业务日期用DATE其实更合适可以省掉一串“2024-03-01 00:00:00.000 和 2024-03-01 23:59:59.997 算不算同一天”的扯皮。4. 核心模块拆解教师档案与课酬结算的完整链路4.1 DAL 层的 DbHelper一个类挡住所有注入和连接泄漏数据访问层如果只允许保留一个类那一定是DbHelper。它要做三件事从配置读取连接串、参数化传入 SQL、用using保证连接归还连接池。写得好整个项目的 SQL 注入风险和连接泄漏风险就都控制在这里了public static class DbHelper { // 查询返回 DataTable适合直接绑定 DataGridView public static DataTable Query(string sql, params SqlParameter[] ps) { var dt new DataTable(); using (var conn new SqlConnection(DbConfig.Conn)) using (var cmd new SqlCommand(sql, conn)) using (var da new SqlDataAdapter(cmd)) { if (ps ! null ps.Length 0) cmd.Parameters.AddRange(ps); da.Fill(dt); // Fill 内部自动 Open/Close不用手写 } return dt; } // 增删改返回受影响行数调用方据此判断是否成功 public static int Execute(string sql, params SqlParameter[] ps) { using (var conn new SqlConnection(DbConfig.Conn)) using (var cmd new SqlCommand(sql, conn)) { if (ps ! null ps.Length 0) cmd.Parameters.AddRange(ps); conn.Open(); return cmd.ExecuteNonQuery(); } } // 事务版结算这种多步操作必须用同一个连接 public static int ExecuteTran(ActionSqlConnection, SqlTransaction work) { using (var conn new SqlConnection(DbConfig.Conn)) { conn.Open(); using (var tran conn.BeginTransaction()) { try { work(conn, tran); tran.Commit(); return 1; } catch { tran.Rollback(); throw; } } } } }三个方法的区别在于使用场景Query用SqlDataAdapter.Fill内部会自己打开和关闭连接适合列表页Execute手动Open返回受影响行数适合单条保存ExecuteTran把一个委托作为工作单元传进来连接和事务都由它管理适合结算。参数统一用params SqlParameter[]调用方写new SqlParameter(TeacherId, id)这样即使参数值来自界面输入框也永远走参数化不会被拼成 SQL 字符串。这是防注入的根本手段不要靠手动转义引号。一个细节Query里没写conn.Open()因为Fill会按需打开但如果写成先Open再Fill用完忘了Close连接池几十次就被耗尽表现出来就是“用一会儿就提示超时”这种问题最难排查。using是后悔药写的时候多敲两行比事后排查省一整天。4.2 教师信息增删改查DataGridView 绑定的正确姿势教师管理窗体是整个系统的入口也是最容易写出 bug 的地方。常见的错误做法是把界面上的值逐个从DataGridView单元格里读出来拼 SQL代码又长又容易漏字段。正确做法是绑定DataTable让控件和内存表同步保存时只遍历有变化的行private DataTable _dtTeacher; private void LoadTeachers(string keyword) { // 关键字过滤用参数化 LIKE不要拼字符串 string sql SELECT TeacherId, TeacherNo, TeacherName, TitleId, DeptName, Phone, BankAccount, Status FROM Teacher WHERE (kw OR TeacherNo LIKE kw OR TeacherName LIKE kw) ORDER BY TeacherNo; _dtTeacher DbHelper.Query(sql, new SqlParameter(kw, % keyword %)); gridTeacher.DataSource _dtTeacher; } private void btnSave_Click(object sender, EventArgs e) { gridTeacher.EndEdit(); // 必须显式结束编辑否则最后一个单元格的值丢失 foreach (DataRow row in _dtTeacher.Rows) { if (row.RowState DataRowState.Unchanged) continue; if (row.RowState DataRowState.Added) { DbHelper.Execute( INSERT INTO Teacher (TeacherNo, TeacherName, TitleId, DeptName, Phone, BankAccount, Status) VALUES (no, name, title, dept, phone, bank, status), new SqlParameter(no, row[TeacherNo]), new SqlParameter(name, row[TeacherName]), new SqlParameter(title, row[TitleId]), new SqlParameter(dept, (object)row[DeptName] ?? DBNull.Value), new SqlParameter(phone, (object)row[Phone] ?? DBNull.Value), new SqlParameter(bank, (object)row[BankAccount] ?? DBNull.Value), new SqlParameter(status, row[Status])); } else if (row.RowState DataRowState.Modified) { DbHelper.Execute( UPDATE Teacher SET TeacherName name, TitleId title, DeptName dept, Phone phone, BankAccount bank, Status status WHERE TeacherId id, new SqlParameter(name, row[TeacherName]), new SqlParameter(title, row[TitleId]), new SqlParameter(dept, (object)row[DeptName] ?? DBNull.Value), new SqlParameter(phone, (object)row[Phone] ?? DBNull.Value), new SqlParameter(bank, (object)row[BankAccount] ?? DBNull.Value), new SqlParameter(status, row[Status]), new SqlParameter(id, row[TeacherId])); } } LoadTeachers(txtKeyword.Text); // 重新拉一遍让自增主键回到前台 }这段代码的关键点有四个。EndEdit()不能省DataGridView在单元格仍处于编辑态时用户刚输入的值还在编辑控件里没有提交到DataTable漏掉这一步的表现是“我明明改了姓名保存后没变”非常容易被误判成数据库没提交。row.RowState用来跳过未修改的行几百条教师挨个UPDATE一遍虽然也能跑但白白产生几百条事务日志。WorkerNo没有出现在UPDATE的SET子句里因为工号是唯一键改了会影响历史结算单的追溯业务上就不允许改。(object)row[DeptName] ?? DBNull.Value是处理 NULL 的固定写法直接传null给SqlParameter在部分版本上会抛参数异常。4.3 课酬结算从点击按钮到写入结算单的完整链路结算窗体的逻辑分三步选学期、预览、确认。预览不落库确认才调存储过程。这里我用ExecuteTran把“调存储过程 写操作日志”包在一个事务里public class SettleService { public DataTable Preview(int termId) { // 预览直接算不写 Settlement 表避免用户点一次就脏一次数据 string sql SELECT d.TeacherId, d.TeacherNo, d.TeacherName, d.TitleName, SUM(d.Hours) AS TotalHours, SUM(ROUND(d.Hours * d.Coefficient * 100.0, 2) d.CampusSubsidy * d.Hours) AS TotalAmount FROM vw_TaskDetail d WHERE d.TermId termId GROUP BY d.TeacherId, d.TeacherNo, d.TeacherName, d.TitleName ORDER BY d.TeacherNo; return DbHelper.Query(sql, new SqlParameter(termId, termId)); } public void Confirm(int termId, string op) { DbHelper.ExecuteTran((conn, tran) { using (var cmd new SqlCommand(usp_CalcSettlement, conn, tran)) { cmd.CommandType CommandType.StoredProcedure; cmd.Parameters.AddWithValue(TermId, termId); cmd.Parameters.AddWithValue(Operator, op); cmd.CommandTimeout 60; // 结算走全量聚合默认 30 秒可能不够 cmd.ExecuteNonQuery(); } // 操作日志和数据变更同一个事务要么都成功要么都不留 using (var log new SqlCommand( INSERT INTO OperLog (Module, RefId, OperUser, OperTime) VALUES (N结算, t, u, GETDATE()), conn, tran)) { log.Parameters.AddWithValue(t, termId); log.Parameters.AddWithValue(u, op); log.ExecuteNonQuery(); } }); } }Preview和Confirm用的是同一套计算口径区别只在于前者不落库。这样安排的好处是用户在预览里看到 3280.50 元点确认后存进去的也一定是 3280.50 元不会因为两处公式写法有细微差异而对不上。有些项目预览在一个 SQL 里算确认在另一个存储过程里算结果两边差几分钱查起来极其痛苦。AddWithValue这个写法有争议它让 SQL Server 自己推断参数类型对于DECIMAL有时会推断成FLOAT引发隐式转换。稳妥一点写成new SqlParameter(TermId, SqlDbType.Int) { Value termId }。我在维护旧项目时遇到过一次termId被推断成nvarchar导致索引失效、查询从 0.1 秒变成 8 秒改回显式类型就好了。CommandTimeout也别忽略。默认 30 秒学期数据多的时候聚合会超时表现出来是“结算点了没反应过了一会儿弹出超时错误”但此时存储过程可能已经执行完了用户再点一次就是重复结算。把超时设长一点同时靠存储过程里的DELETE INSERT和唯一约束兜底这才是双保险。5. 踩坑排查跑不起来、连不上库、算错钱的那几个坑5.1 环境和连接类环境问题不是配置问题现象一双击 sln 打开后右键生成失败提示“找不到目标框架 .NETFramework,Versionv4.7.2”。原因这套项目用的是 .NET Framework不是 .NET Core / .NET 8新机器上只装了运行时没装开发者包或者项目重定向到了本机没有的版本。 解决在项目属性里把“目标框架”改成机器上已有的版本比如 4.6.1 或 4.8改完顺手把packages.config里引用的System.Data.SqlClient之类检查一遍或者直接安装对应版本的 Developer Pack。不要图省事改成 .NET 8那要动整个 csproj 的格式改造成本远大于装个包。现象二登录时报“在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误”。原因最常见的是实例名写错其次是 SQL Server Browser 服务没启动再次是 TCP/IP 协议没启用。Express 版默认是命名实例连接串写成.一定连不上。 解决打开services.msc确认SQL Server (SQLEXPRESS)和SQL Server Browser两个服务都在运行在 SQL Server 配置管理器里把TCP/IP启用连接串改成Data Source.\SQLEXPRESS再试。如果是在另一台机器上连还要在防火墙里放行 1433 端口命名实例是动态端口开 Browser 更省事。现象三Keeps asking 登录失败提示“用户 sa 登录失败”。原因装库的时候选了 Windows 身份验证模式sa账号被禁用而连接串里写的是User IDsa。 解决用 Windows 认证登进 SSMS在服务器属性里改成“混合模式”启用sa并设密码更好的做法是新建一个只有ETMS库读写权限的专用账号etms_user客户端用它连避免用超级管理员账号跑业务系统。5.2 数据与计算类错在第四位小数上现象四两个人先后点“结算”Settlement 表里同一学期同一教师出现两条记录。原因代码里先SELECT判断有没有结算过再INSERT判断和写入之间有窗口期两个客户端同时通过判断就都插进去了。 解决靠数据库的唯一约束UQ_Settle (TermId, TeacherId)兜底插入冲突时捕获SqlException的 2627 错误号提示“该教师本学期已结算”。代码里的if判断只能防误操作防不了并发别把它当锁用。现象五课酬总额和财务手算的差几分钱。原因一是用了double参与计算浮点数在二进制下无法精确表示 0.1 这类小数二是Math.Round默认是银行家舍入2.345 会变成 2.34 而不是 2.35。 解决金额全链路用decimalSQL 端用DECIMAL(12,2)四舍五入显式写Math.Round(x, 2, MidpointRounding.AwayFromZero)SQL 端ROUND(x, 2)默认就是四舍五入但要确认没有混入double类型的计算列。改完后拿三条边界数据1.005、2.675、0.125跑一遍验证。现象六教师姓名存进去变成问号“??”或者生僻字变成方框。原因TeacherName字段建成了VARCHAR插入时又没加N前缀中文字符在非 Unicode 排序规则下被截断。 解决字段类型改NVARCHARSQL 里的字符串字面量统一加N前缀C# 侧SqlParameter用SqlDbType.NVarChar。改的时候注意已有数据要先备份ALTER COLUMN之后再补一遍数据。6. 二次开发把课酬规则和导出做成能改的接手这类项目最值钱的改造不是加界面而是把“算钱”这件事从代码里挪出来。当前版本的单位课时费100.0还内联在存储过程里职称系数虽然进了Title表但改一次系数会把历史学期一起改掉。我的做法是加一张带生效区间的规则表CREATE TABLE PayRule ( RuleId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, -- 按学期生效历史账不受影响 UnitPrice DECIMAL(8,2) NOT NULL, -- 单位课时费 CampusFee DECIMAL(8,2) NOT NULL, -- 跨校区每学时补贴 CreateTime DATETIME NOT NULL DEFAULT(GETDATE()) );结算存储过程里把两个硬编码值替换成从PayRule按TermId查出来的变量查不到就RAISERROR提示“该学期未配置课酬规则”。这样一来新学期开学只用在界面上录一条规则不用重新编译发布。改完必须验证先造 3 条授课任务1.5 学时讲师、2 学时副教授、跨校区 1 学时手算三遍总额再和系统跑出来的对比一分不差才算通过。第二个改造是导出。教务那边最终要的是 Excel别用DataGridView直接打印加个导出按钮用 NPOI 写 xlsx 三十行代码就够或者退一步先导 CSV——注意 CSV 用 UTF-8 带 BOM否则 Excel 打开中文又是乱码这个坑我踩过不止一次。导出的列顺序和表头要和财务给的模板严格一致别自作主张加字段。那以后我每次改结算逻辑都会强制走一遍“三组边界数据手算 存储过程重复执行两次看结果是否一致”的流程。课酬这种涉及金额的计算一次算错就要重新解释宁可多花二十分钟验证。希望这些拆解能帮你把这套系统顺利跑起来也少踩几个我踩过的坑。本文还有配套的精品资源点击获取
简介外聘教师管理系统是一套面向学校教务与人事管理场景的C# WinForms课程设计/小型管理系统源码采用SQL Server数据库围绕外聘教师信息维护、按院系/课程/姓名查询与统计、按代课数量和代课金级别计算工资、系部课程及代课金级别维护、登录权限与改密等模块展开适合学习桌面端CRUD、统计查询和权限控制的学生与开发者参考。压缩包共97个文件约35.47MB包含26个cs源码、25张界面截图、多组resx/resources资源、dll与exe运行文件以及mdf/ldf数据库、sln/csproj工程和配置文件目录覆盖窗体设计、业务逻辑与数据库部分。已有437人学习下载可用于对照完整工程理解窗体跳转、查询统计和普通用户只读权限的实现包内附SQL2012数据库修改数据库连接后即可运行调试。1. 外聘教师管理系统一份课酬表从 Excel 搬进 C# 加 SQL 的全过程每到学期末教务办最头疼的事情不是排课而是核算外聘老师的课酬课时数记录在教务系统的导出表里职称系数保存在一张随手更新的 Excel 中跨校区上课的补贴又记在另一个文档中三份数据反复核对一遍通常要花两天时间一旦中间改了一门课就得从头再算一遍。这套外聘教师管理系统就是把这套流程固化下来——用 C# WinForms 做录入和结算界面用 SQL Server 存放教师档案、授课任务和结算单点击“生成结算”后直接生成一张可以打印的课酬表。它适合三类人看做课程设计或毕设、需要一套完整三层架构范例的在校开发者需要给二级学院做小型内网工具的独立开发者以及接手了这类历史项目、要在一堆DataGridView里加字段的维护者。下面按照我拆解项目的顺序展开从解压后先看哪里到核心的课酬计算怎样才算对再到如何改成可配置规则。2. 技术选型与目录结构WinForms 加 ADO.NET 三层怎么落地2.1 为什么是 C# WinForms SQL Server而不是 Web先说结论这套系统的使用场景是内网办公用户数一只手数得过来数据量在万级以内所以选用 WinForms 不是技术保守而是把维护成本压到最低。教务办只有两三台电脑一台装数据库其余装客户端双击 exe 就能用不需要 IIS不需要域名也不用担心浏览器版本兼容。DataGridView这种控件天生适合“一行一个老师、一列一个字段”的录入场景改一个单元格就能修改比 Web 表单提交后还要刷新页面方便得多。数据库选 SQL Server 也是同一个思路外聘教师、授课任务、结算单之间存在明确的主外键关系用视图和存储过程把“按学期汇总课酬”这个动作下沉到数据库客户端只负责展示结果。如果换成 SQLite部署是更省事但多台机器共享同一份数据时就会很麻烦换成 MySQL 也能运行只是这套代码里大量使用SqlParameter、SqlDataAdapter迁移要修改的访问层代码不少没必要。代价也要说清楚避免使用后才发现问题。WinForms 的界面风格比较陈旧高分屏缩放下控件会模糊需要在app.manifest里开启 DPI 感知客户端更新时需要把新的 exe 拷贝过去后续可以考虑 ClickOnce并发能力很弱两个人同时点击“结算”是唯一的真实并发点这一点在第 5 章的避坑里还会遇到。放到这个项目上这些代价都可以接受但如果以后要支持外聘教师自己登录查询课酬就应当切换到 Web不应强行修改 WinForms。2.2 从 .rar 解压后先看这四个目录解压之后不要急着双击 sln 运行——先看清楚分层修改代码时才知道该在哪里改。按照这个项目场景合格开发一般会拆成 Model / DAL / BLL / UI 四层加一个独立的数据库脚本目录。我把它整理成表格方便对照路径职责修改频率ETMS.sln解决方案入口一般包含 4 个项目低DB/ETMS.sql建库建表、视图、存储过程、初始字典数据中加字段必改Model/实体类如Teacher、TeachingTask、Settlement中DAL/DbHelper 各表的XxxDAL只写 SQL 和参数高BLL/业务规则课酬计算、学期状态校验都在这一层高UI/窗体FrmTeacher、FrmSettle、FrmMain高App.config连接字符串、日志开关部署时改四个项目的引用关系是单向的UI 引用 BLLBLL 引用 DAL 和 ModelDAL 引用 ModelModel 谁都不引用。这条引用必须遵守——我见过不少同类项目图省事在窗体里直接new SqlConnection连接数据库结果连接字符串散落在二十多个文件里换一台机器部署时要全局搜索并替换那才是真正的麻烦。判断一个 WinForms 项目分层是否清晰有一个很快的检查方法打开任意一个.cs窗体文件搜索SqlConnection。如果搜到了说明它正在绕过 BLL 直接访问数据库这个项目的可维护性就要打折扣如果整个 UI 目录一个都搜不到说明分层是干净的后续加字段只需要改 DAL 和 BLL。2.3 连接字符串与 App.config 的正确写法部署时最容易出问题的就是这一步。序里写死的连接字符串在新机器上一定会失败所以要统一放到App.config的connectionStrings节点里代码只按名字读取?xml version1.0 encodingutf-8? configuration connectionStrings !-- Data Source 用 机器名\实例名本机默认实例可写 . 或 (local) -- add nameETMS connectionStringData Source.;Initial CatalogETMS;User IDetms_user;Password******;Connect Timeout15 providerNameSystem.Data.SqlClient / /connectionStrings appSettings !-- 结算时是否允许跨学期重算默认关闭防止误操作改历史账 -- add keyAllowResettle valuefalse / /appSettings /configuration读取的时候包一层避免配置缺失时抛出的异常让人摸不着头脑// DAL/DbConfig.cs public static class DbConfig { private static string _conn; public static string Conn { get { if (_conn null) { var setting ConfigurationManager.ConnectionStrings[ETMS]; if (setting null) throw new ConfigurationErrorsException(App.config 中缺少名为 ETMS 的连接字符串); _conn setting.ConnectionString; } return _conn; } } // 单元测试或临时切库时用正式运行不会走这里 public static void Override(string conn) { _conn conn; } }参数里几个点要交代清楚。Data Source.表示本机默认实例如果安装的是命名实例比如装了 Express 版必须写成.\SQLEXPRESSInitial Catalog是库名改名了这里要同步修改Connect Timeout15是连接超时默认也是 15 秒显式写出来是为了让运维看到认证方式建议用 SQL 账号而不是 Windows 集成认证因为教务办的机器不一定会加入域Integrated SecurityTrue在跨机器调用时反而会变成新的麻烦。AllowResettle这个开关在后续结算逻辑里会用到用来防止历史学期被重复计算。3. 数据库设计教师、授课任务、结算单三张主表怎么串3.1 建表脚本与字段设计整个系统的数据模型其实是一条链一个教师在一个学期里承担若干门课的授课任务学期结束时把所有任务按职称系数折算成课酬写进结算单。所以核心是五张表加两张字典表。我把关键部分的建表语句贴出来字段类型是血泪经验调过的-- 职称字典系数决定课酬倍率放在表里而不是写死在代码里 CREATE TABLE Title ( TitleId INT IDENTITY(1,1) PRIMARY KEY, TitleName NVARCHAR(20) NOT NULL, -- 助教/讲师/副教授/教授 Coefficient DECIMAL(4,2) NOT NULL, -- 1.00 / 1.20 / 1.50 / 1.80 IsActive BIT NOT NULL DEFAULT(1) ); CREATE TABLE Teacher ( TeacherId INT IDENTITY(1,1) PRIMARY KEY, TeacherNo VARCHAR(20) NOT NULL, -- 工号唯一纯 ASCII 用 varchar TeacherName NVARCHAR(30) NOT NULL, -- 姓名必须 nvarchar否则生僻字乱码 TitleId INT NOT NULL, DeptName NVARCHAR(50) NULL, -- 外聘教师可能不属于任何院系 Phone VARCHAR(20) NULL, BankAccount VARCHAR(32) NULL, Status TINYINT NOT NULL DEFAULT(1), -- 1 在职 0 停用 CreateTime DATETIME NOT NULL DEFAULT(GETDATE()), CONSTRAINT UQ_Teacher_No UNIQUE (TeacherNo), CONSTRAINT FK_Teacher_Title FOREIGN KEY (TitleId) REFERENCES Title(TitleId) ); -- 授课任务一门课一个外聘老师一条同一老师同一课程可多条不同班级 CREATE TABLE TeachingTask ( TaskId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, TeacherId INT NOT NULL, CourseName NVARCHAR(60) NOT NULL, ClassName NVARCHAR(60) NULL, Campus NVARCHAR(20) NULL, -- 校区跨校区有补贴 Hours DECIMAL(6,1) NOT NULL, -- 允许 0.5 学时 StudentCount INT NULL, CONSTRAINT FK_Task_Teacher FOREIGN KEY (TeacherId) REFERENCES Teacher(TeacherId) ); -- 结算单一个学期一个老师一条TotalAmount 是最终发放金额 CREATE TABLE Settlement ( SettleId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, TeacherId INT NOT NULL, TotalHours DECIMAL(8,1) NOT NULL, TotalAmount DECIMAL(12,2) NOT NULL, Status TINYINT NOT NULL DEFAULT(0), -- 0 草稿 1 已确认 Operator NVARCHAR(30) NULL, CreateTime DATETIME NOT NULL DEFAULT(GETDATE()), CONSTRAINT UQ_Settle UNIQUE (TermId, TeacherId) -- 唯一约束是幂等的最后一道锁 );这段脚本里有三个决定必须说明。第一TeacherName用NVARCHAR而TeacherNo用VARCHAR这是有意的工号是数字和字母varchar节省空间且索引更小姓名里会出现生僻字varchar在非 Unicode 排序规则下直接存成问号那就是数据事故。第二Hours用DECIMAL(6,1)而不是INT教务这边确实存在 1.5 学时、0.5 学时的情况用整数会出现“明明 24 学时算出来 23”的玄学问题。第三UQ_Settle这个唯一约束看起来可有可无实际上是并发重复结算的最后一道防线第 5 章会展开讲它为什么比代码里的if判断更可靠。3.2 视图与存储过程把课酬汇总下沉到数据库课酬的计算口径是课时 × 职称系数 × 单位课时费 跨校区补贴。这个公式一旦写死在 C# 里每次调整口径都要重新编译发版放到存储过程里只改脚本就行。我先建一个明细视图把任务、教师、职称串起来CREATE VIEW vw_TaskDetail AS SELECT t.TaskId, t.TermId, t.TeacherId, te.TeacherNo, te.TeacherName, ti.TitleName, ti.Coefficient, t.CourseName, t.ClassName, t.Campus, t.Hours, -- 跨校区补贴按每学时固定 10 元放到配置表更好这里先内联 CASE WHEN t.Campus IS NOT NULL AND t.Campus N主校区 THEN 10.00 ELSE 0.00 END AS CampusSubsidy FROM TeachingTask t JOIN Teacher te ON te.TeacherId t.TeacherId JOIN Title ti ON ti.TitleId te.TitleId;结算存储过程我一般写成“先清理草稿再重算”保证多次执行的最终结果一致CREATE PROCEDURE usp_CalcSettlement TermId INT, Operator NVARCHAR(30) AS BEGIN SET NOCOUNT ON; BEGIN TRY BEGIN TRAN; -- 1. 已确认的单据不允许重算直接抛出业务错误 IF EXISTS (SELECT 1 FROM Settlement WHERE TermId TermId AND Status 1) BEGIN RAISERROR(N该学期已有确认的结算单请先反确认, 16, 1); END -- 2. 清掉旧草稿实现幂等 DELETE FROM Settlement WHERE TermId TermId AND Status 0; -- 3. 按教师汇总用 ROUND 显式指定四舍五入方式 INSERT INTO Settlement (TermId, TeacherId, TotalHours, TotalAmount, Status, Operator) SELECT TermId, d.TeacherId, SUM(d.Hours), SUM(ROUND(d.Hours * d.Coefficient * 100.0, 2) d.CampusSubsidy * d.Hours), 0, Operator FROM vw_TaskDetail d WHERE d.TermId TermId GROUP BY d.TeacherId; COMMIT; END TRY BEGIN CATCH IF TRANCOUNT 0 ROLLBACK; THROW; -- 把原始错误抛给上层不要在存储过程里吞掉 END CATCH END逐段看TermId是学期主键UI 上选哪一学期就传哪个Operator记录操作人出问题时能追到是谁点击的。第 1 步的RAISERROR用的是THROW之外的业务报错方式16表示可以捕获的用户级错误。第 3 步的SUM(ROUND(...))是先按单条任务四舍五入再汇总而不是汇总完再四舍五入这两种算法在 3 条以上任务时会差出几分钱财务那边对不上账的根源往往就在这里。100.0是单位课时费实际部署时应当从配置表读取我这里是简化版。THROW而不吞异常这一点值得单独说。很多同类的存储过程在CATCH里只写SELECT ERROR_MESSAGE()然后RETURN调用方拿到的是“执行成功但没数据”排查时完全是黑匣子。用THROW把原始错误码和消息抛回 ADO.NETC# 侧catch (SqlException ex)能直接拿到错误号和文本定位快得多。3.3 索引与数据量预估别等到卡了才加这套系统的真实数据量大概是教师几百条每学期授课任务两三千条结算单几百条。这个量级下全表扫描也不会明显卡顿但该建的索引还是要建因为它的成本几乎为零-- 结算时按学期 教师聚合这个是覆盖面最广的 CREATE NONCLUSTERED INDEX IX_Task_Term_Teacher ON TeachingTask (TermId, TeacherId) INCLUDE (Hours, Campus); -- 教师列表按状态筛选 按工号排序 CREATE NONCLUSTERED INDEX IX_Teacher_Status_No ON Teacher (Status, TeacherNo);INCLUDE里放Hours和Campus是为了让结算查询走覆盖索引不用回表。这个技巧在几千行数据上感知不到但如果哪天有院系把历史五年的数据一起导进来就是能不能接受的区别。字段类型上还有两个常见误用要提醒金额一律DECIMAL(12,2)不要用MONEYMONEY在参与复杂表达式时精度行为不直观而且各家数据库迁移时不兼容日期用DATETIME2比DATETIME精度更高但这个项目里全是“某年某月某日”的业务日期用DATE其实更合适可以省掉一串“2024-03-01 00:00:00.000 和 2024-03-01 23:59:59.997 算不算同一天”的扯皮。4. 核心模块拆解教师档案与课酬结算的完整链路4.1 DAL 层的 DbHelper一个类挡住所有注入和连接泄漏数据访问层如果只允许保留一个类那一定是DbHelper。它要做三件事从配置读取连接串、参数化传入 SQL、用using保证连接归还连接池。写得好整个项目的 SQL 注入风险和连接泄漏风险就都控制在这里了public static class DbHelper { // 查询返回 DataTable适合直接绑定 DataGridView public static DataTable Query(string sql, params SqlParameter[] ps) { var dt new DataTable(); using (var conn new SqlConnection(DbConfig.Conn)) using (var cmd new SqlCommand(sql, conn)) using (var da new SqlDataAdapter(cmd)) { if (ps ! null ps.Length 0) cmd.Parameters.AddRange(ps); da.Fill(dt); // Fill 内部自动 Open/Close不用手写 } return dt; } // 增删改返回受影响行数调用方据此判断是否成功 public static int Execute(string sql, params SqlParameter[] ps) { using (var conn new SqlConnection(DbConfig.Conn)) using (var cmd new SqlCommand(sql, conn)) { if (ps ! null ps.Length 0) cmd.Parameters.AddRange(ps); conn.Open(); return cmd.ExecuteNonQuery(); } } // 事务版结算这种多步操作必须用同一个连接 public static int ExecuteTran(ActionSqlConnection, SqlTransaction work) { using (var conn new SqlConnection(DbConfig.Conn)) { conn.Open(); using (var tran conn.BeginTransaction()) { try { work(conn, tran); tran.Commit(); return 1; } catch { tran.Rollback(); throw; } } } } }三个方法的区别在于使用场景Query用SqlDataAdapter.Fill内部会自己打开和关闭连接适合列表页Execute手动Open返回受影响行数适合单条保存ExecuteTran把一个委托作为工作单元传进来连接和事务都由它管理适合结算。参数统一用params SqlParameter[]调用方写new SqlParameter(TeacherId, id)这样即使参数值来自界面输入框也永远走参数化不会被拼成 SQL 字符串。这是防注入的根本手段不要靠手动转义引号。一个细节Query里没写conn.Open()因为Fill会按需打开但如果写成先Open再Fill用完忘了Close连接池几十次就被耗尽表现出来就是“用一会儿就提示超时”这种问题最难排查。using是后悔药写的时候多敲两行比事后排查省一整天。4.2 教师信息增删改查DataGridView 绑定的正确姿势教师管理窗体是整个系统的入口也是最容易写出 bug 的地方。常见的错误做法是把界面上的值逐个从DataGridView单元格里读出来拼 SQL代码又长又容易漏字段。正确做法是绑定DataTable让控件和内存表同步保存时只遍历有变化的行private DataTable _dtTeacher; private void LoadTeachers(string keyword) { // 关键字过滤用参数化 LIKE不要拼字符串 string sql SELECT TeacherId, TeacherNo, TeacherName, TitleId, DeptName, Phone, BankAccount, Status FROM Teacher WHERE (kw OR TeacherNo LIKE kw OR TeacherName LIKE kw) ORDER BY TeacherNo; _dtTeacher DbHelper.Query(sql, new SqlParameter(kw, % keyword %)); gridTeacher.DataSource _dtTeacher; } private void btnSave_Click(object sender, EventArgs e) { gridTeacher.EndEdit(); // 必须显式结束编辑否则最后一个单元格的值丢失 foreach (DataRow row in _dtTeacher.Rows) { if (row.RowState DataRowState.Unchanged) continue; if (row.RowState DataRowState.Added) { DbHelper.Execute( INSERT INTO Teacher (TeacherNo, TeacherName, TitleId, DeptName, Phone, BankAccount, Status) VALUES (no, name, title, dept, phone, bank, status), new SqlParameter(no, row[TeacherNo]), new SqlParameter(name, row[TeacherName]), new SqlParameter(title, row[TitleId]), new SqlParameter(dept, (object)row[DeptName] ?? DBNull.Value), new SqlParameter(phone, (object)row[Phone] ?? DBNull.Value), new SqlParameter(bank, (object)row[BankAccount] ?? DBNull.Value), new SqlParameter(status, row[Status])); } else if (row.RowState DataRowState.Modified) { DbHelper.Execute( UPDATE Teacher SET TeacherName name, TitleId title, DeptName dept, Phone phone, BankAccount bank, Status status WHERE TeacherId id, new SqlParameter(name, row[TeacherName]), new SqlParameter(title, row[TitleId]), new SqlParameter(dept, (object)row[DeptName] ?? DBNull.Value), new SqlParameter(phone, (object)row[Phone] ?? DBNull.Value), new SqlParameter(bank, (object)row[BankAccount] ?? DBNull.Value), new SqlParameter(status, row[Status]), new SqlParameter(id, row[TeacherId])); } } LoadTeachers(txtKeyword.Text); // 重新拉一遍让自增主键回到前台 }这段代码的关键点有四个。EndEdit()不能省DataGridView在单元格仍处于编辑态时用户刚输入的值还在编辑控件里没有提交到DataTable漏掉这一步的表现是“我明明改了姓名保存后没变”非常容易被误判成数据库没提交。row.RowState用来跳过未修改的行几百条教师挨个UPDATE一遍虽然也能跑但白白产生几百条事务日志。WorkerNo没有出现在UPDATE的SET子句里因为工号是唯一键改了会影响历史结算单的追溯业务上就不允许改。(object)row[DeptName] ?? DBNull.Value是处理 NULL 的固定写法直接传null给SqlParameter在部分版本上会抛参数异常。4.3 课酬结算从点击按钮到写入结算单的完整链路结算窗体的逻辑分三步选学期、预览、确认。预览不落库确认才调存储过程。这里我用ExecuteTran把“调存储过程 写操作日志”包在一个事务里public class SettleService { public DataTable Preview(int termId) { // 预览直接算不写 Settlement 表避免用户点一次就脏一次数据 string sql SELECT d.TeacherId, d.TeacherNo, d.TeacherName, d.TitleName, SUM(d.Hours) AS TotalHours, SUM(ROUND(d.Hours * d.Coefficient * 100.0, 2) d.CampusSubsidy * d.Hours) AS TotalAmount FROM vw_TaskDetail d WHERE d.TermId termId GROUP BY d.TeacherId, d.TeacherNo, d.TeacherName, d.TitleName ORDER BY d.TeacherNo; return DbHelper.Query(sql, new SqlParameter(termId, termId)); } public void Confirm(int termId, string op) { DbHelper.ExecuteTran((conn, tran) { using (var cmd new SqlCommand(usp_CalcSettlement, conn, tran)) { cmd.CommandType CommandType.StoredProcedure; cmd.Parameters.AddWithValue(TermId, termId); cmd.Parameters.AddWithValue(Operator, op); cmd.CommandTimeout 60; // 结算走全量聚合默认 30 秒可能不够 cmd.ExecuteNonQuery(); } // 操作日志和数据变更同一个事务要么都成功要么都不留 using (var log new SqlCommand( INSERT INTO OperLog (Module, RefId, OperUser, OperTime) VALUES (N结算, t, u, GETDATE()), conn, tran)) { log.Parameters.AddWithValue(t, termId); log.Parameters.AddWithValue(u, op); log.ExecuteNonQuery(); } }); } }Preview和Confirm用的是同一套计算口径区别只在于前者不落库。这样安排的好处是用户在预览里看到 3280.50 元点确认后存进去的也一定是 3280.50 元不会因为两处公式写法有细微差异而对不上。有些项目预览在一个 SQL 里算确认在另一个存储过程里算结果两边差几分钱查起来极其痛苦。AddWithValue这个写法有争议它让 SQL Server 自己推断参数类型对于DECIMAL有时会推断成FLOAT引发隐式转换。稳妥一点写成new SqlParameter(TermId, SqlDbType.Int) { Value termId }。我在维护旧项目时遇到过一次termId被推断成nvarchar导致索引失效、查询从 0.1 秒变成 8 秒改回显式类型就好了。CommandTimeout也别忽略。默认 30 秒学期数据多的时候聚合会超时表现出来是“结算点了没反应过了一会儿弹出超时错误”但此时存储过程可能已经执行完了用户再点一次就是重复结算。把超时设长一点同时靠存储过程里的DELETE INSERT和唯一约束兜底这才是双保险。5. 踩坑排查跑不起来、连不上库、算错钱的那几个坑5.1 环境和连接类环境问题不是配置问题现象一双击 sln 打开后右键生成失败提示“找不到目标框架 .NETFramework,Versionv4.7.2”。原因这套项目用的是 .NET Framework不是 .NET Core / .NET 8新机器上只装了运行时没装开发者包或者项目重定向到了本机没有的版本。 解决在项目属性里把“目标框架”改成机器上已有的版本比如 4.6.1 或 4.8改完顺手把packages.config里引用的System.Data.SqlClient之类检查一遍或者直接安装对应版本的 Developer Pack。不要图省事改成 .NET 8那要动整个 csproj 的格式改造成本远大于装个包。现象二登录时报“在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误”。原因最常见的是实例名写错其次是 SQL Server Browser 服务没启动再次是 TCP/IP 协议没启用。Express 版默认是命名实例连接串写成.一定连不上。 解决打开services.msc确认SQL Server (SQLEXPRESS)和SQL Server Browser两个服务都在运行在 SQL Server 配置管理器里把TCP/IP启用连接串改成Data Source.\SQLEXPRESS再试。如果是在另一台机器上连还要在防火墙里放行 1433 端口命名实例是动态端口开 Browser 更省事。现象三Keeps asking 登录失败提示“用户 sa 登录失败”。原因装库的时候选了 Windows 身份验证模式sa账号被禁用而连接串里写的是User IDsa。 解决用 Windows 认证登进 SSMS在服务器属性里改成“混合模式”启用sa并设密码更好的做法是新建一个只有ETMS库读写权限的专用账号etms_user客户端用它连避免用超级管理员账号跑业务系统。5.2 数据与计算类错在第四位小数上现象四两个人先后点“结算”Settlement 表里同一学期同一教师出现两条记录。原因代码里先SELECT判断有没有结算过再INSERT判断和写入之间有窗口期两个客户端同时通过判断就都插进去了。 解决靠数据库的唯一约束UQ_Settle (TermId, TeacherId)兜底插入冲突时捕获SqlException的 2627 错误号提示“该教师本学期已结算”。代码里的if判断只能防误操作防不了并发别把它当锁用。现象五课酬总额和财务手算的差几分钱。原因一是用了double参与计算浮点数在二进制下无法精确表示 0.1 这类小数二是Math.Round默认是银行家舍入2.345 会变成 2.34 而不是 2.35。 解决金额全链路用decimalSQL 端用DECIMAL(12,2)四舍五入显式写Math.Round(x, 2, MidpointRounding.AwayFromZero)SQL 端ROUND(x, 2)默认就是四舍五入但要确认没有混入double类型的计算列。改完后拿三条边界数据1.005、2.675、0.125跑一遍验证。现象六教师姓名存进去变成问号“??”或者生僻字变成方框。原因TeacherName字段建成了VARCHAR插入时又没加N前缀中文字符在非 Unicode 排序规则下被截断。 解决字段类型改NVARCHARSQL 里的字符串字面量统一加N前缀C# 侧SqlParameter用SqlDbType.NVarChar。改的时候注意已有数据要先备份ALTER COLUMN之后再补一遍数据。6. 二次开发把课酬规则和导出做成能改的接手这类项目最值钱的改造不是加界面而是把“算钱”这件事从代码里挪出来。当前版本的单位课时费100.0还内联在存储过程里职称系数虽然进了Title表但改一次系数会把历史学期一起改掉。我的做法是加一张带生效区间的规则表CREATE TABLE PayRule ( RuleId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, -- 按学期生效历史账不受影响 UnitPrice DECIMAL(8,2) NOT NULL, -- 单位课时费 CampusFee DECIMAL(8,2) NOT NULL, -- 跨校区每学时补贴 CreateTime DATETIME NOT NULL DEFAULT(GETDATE()) );结算存储过程里把两个硬编码值替换成从PayRule按TermId查出来的变量查不到就RAISERROR提示“该学期未配置课酬规则”。这样一来新学期开学只用在界面上录一条规则不用重新编译发布。改完必须验证先造 3 条授课任务1.5 学时讲师、2 学时副教授、跨校区 1 学时手算三遍总额再和系统跑出来的对比一分不差才算通过。第二个改造是导出。教务那边最终要的是 Excel别用DataGridView直接打印加个导出按钮用 NPOI 写 xlsx 三十行代码就够或者退一步先导 CSV——注意 CSV 用 UTF-8 带 BOM否则 Excel 打开中文又是乱码这个坑我踩过不止一次。导出的列顺序和表头要和财务给的模板严格一致别自作主张加字段。那以后我每次改结算逻辑都会强制走一遍“三组边界数据手算 存储过程重复执行两次看结果是否一致”的流程。课酬这种涉及金额的计算一次算错就要重新解释宁可多花二十分钟验证。希望这些拆解能帮你把这套系统顺利跑起来也少踩几个我踩过的坑。本文还有配套的精品资源点击获取
