简介这是一套基于ASP.NET WebForms开发的在线值班管理系统面向需要实现单位内部排班、值班登记、调班审批、历史查询等功能的中小企业、行政部门或开发学习者也可作为高校课程设计题目。资源压缩包共77个文件、大小仅8.39MB主要包含aspx页面源码、ascx用户控件、css样式、JavaScript脚本、DLL业务类库以及Access数据库文件前后端目录结构完整可配合Visual Studio 2010与Windows Server 2003环境部署运行。目前已有491人浏览学习适合作为ASP.NET Web项目或Access数据操作的入门参考。借助该资源读者既能直接还原整套系统的目录组织与代码写法理解aspx与ascx的页面复用、Ajax无刷新交互、WdatePicker日历控件集成等实现细节也可以基于自带的mdb数据库和编译好的业务DLL进行二次开发调整值班类型、人员权限、统计报表等逻辑快速落地改造成自己单位的排班管理系统节省从零搭建的时间。1. 值班管理系统为什么值得用 ASP.NET 重做一遍值班排班这件事在绝大多数单位里还是靠一张 Excel 表或者微信群接龙来维持的。月初排班的人把表格做出来有换班需求就往群里发消息月底再人工对着记录统计每个人值了多少次。这个过程损耗很大换班改来改去容易覆盖别人的记录统计时漏数一天就要折腾半天更别提节假日排班这种本来就不规则的场景。用 ASP.NET 搭一个值班管理系统核心就是把排班变成常态化流程值班管理员在后台维护班次、生成排班表值班人员登录后查看自己的排班、提交换班申请负责人审批后系统自动落账月底出统计报表。适合的单位画像很清晰有固定值班需求的中小团队现有流程靠表格或口头协调想用最低成本把排班数据化、留痕、可追溯。这篇内容会从框架选型讲到数据库设计、排班核心逻辑、最后到避坑全程按可复现的路径走。2. 先定技术路线选 ASP.NET Core 还是 .NET Framework以及数据模型怎么搭2.1 用 ASP.NET Core 还是 .NET Framework先看部署环境再定框架值班管理系统看起来简单但选框架这一步如果选错后面维护会很痛苦。我一般会先问一个问题服务器是谁的、装了什么系统、能不能装新运行时。如果目标部署环境是 Windows Server 加 IIS而且单位的运维不允许你随便装 .NET 8 Runtime那老牌的 .NET Framework 4.8 ASP.NET MVC 反而是稳妥选择。它跑在 IIS 的经典应用池里不需要额外装 SDK系统只要Windows Server 2012 R2及以上基本都自带.NET Framework 4.x。缺点是开发体验偏老依赖 NuGet 包版本兼容性写单元测试也没那么顺。如果是新采购的服务器或者允许容器化部署那毫不犹豫选 ASP.NET Core版本至少 .NET 6 以上.NET 8 更好。跨平台、性能好、依赖注入内置、身份认证中间件很干净发布出来一个自包含目录可以直接跑。Razor Pages 就够用不必上 MVC因为值班系统的页面交互复杂度不高Razor Pages 的 PageModel 模式反而让每个功能页自包含代码量更少。我的建议是追求长期可维护性走 ASP.NET Core EF Core Razor Pages这是目前社区里最主流、遇到问题能搜到最多答案的组合。下面所有示例代码都按这个组合写。2.2 值班排班的数据模型一份能落地的 ER 设计值班系统数据模型并不复杂但字段设计会直接决定后面换班、统计功能的成本。核心表是这几张用户表、班次表、排班表、换班申请单。用户表不必多说存储姓名、工号、角色管理员/普通值班员。班次表用来描述一天里的时间段比如早班 08:00-16:00、晚班 16:00-24:00、夜班 00:00-08:00。排班表是核心每一条记录表示“某人在某天值某个班”字段里除了外键外还要有一个状态字段来标识这个班次是正常排班、被换过还是已调休这个状态字段后面在统计和冲突检查里都会用到。public class Shift { public int Id { get; set; } public string Name { get; set; } // 班次名称早班/晚班/夜班 public TimeSpan StartTime { get; set; } // 开始时间 public TimeSpan EndTime { get; set; } // 结束时间 public int SortOrder { get; set; } // 显示顺序 } public class ScheduleRecord { public int Id { get; set; } public int UserId { get; set; } public int ShiftId { get; set; } public DateTime WorkDate { get; set; } // 值班日期只取日期部分 public int Status { get; set; } // 0正常 1已换班 2调休 public DateTime CreatedAt { get; set; } }这里的逻辑说明WorkDate不要存DateTime.Now的完整时间统一只存日期部分避免跨夜班次夜班跨到第二天在比对时出现时间偏移问题。Status字段用 int 而不是 bool 是给后续扩展留空间调休和换班是两种不同状态。ShiftId和WorkDate上要建联合唯一索引保证同一个值班员同一天只能有一条记录这是数据层兜底防重。参数上的细节TimeSpan类型在 SQL Server 里映射为time适合表示班次的起止时间。如果某个班次跨天比如夜班 20:00 到次日 04:00存储时让StartTime EndTime在代码里判断逻辑稍后处理不要在数据库里拆两段。protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.EntityScheduleRecord() .HasIndex(r new { r.WorkDate, r.UserId }) .IsUnique(); }这里注意如果后续要支持“同一天既值白班又值夜班”这种特殊情况就需要调整策略把唯一索引拆成(WorkDate, UserId, ShiftId)还是直接去掉唯一索引靠应用层判断。我一般保留联合唯一索引因为大多数单位不允许同一天多班次如果真有这种需求应该走审批而不是放开数据库约束。3. 把一组最小可运行的项目搭起来命令、文件、初始化3.1 用 dotnet CLI 从零建项目并跑通本地在本地动手前先确认环境安装了 .NET SDK 8.0能用dotnet --version输出版本号。建项目用 Razor Pages 模板命名按单位项目惯例来比如 DutySystem。先创建项目然后依次加 EF Core 相关包。dotnet new webapp -n DutySystem -o DutySystem cd DutySystem dotnet add package Microsoft.EntityFrameworkCore.SqlServer dotnet add package Microsoft.EntityFrameworkCore.Tools dotnet add package Microsoft.EntityFrameworkCore.Design参数说明webapp模板生成的是带 Razor Pages 的 ASP.NET Core 项目里面自带空首页和隐私页。三个包各有分工SqlServer提供数据库驱动Tools提供迁移命令Design是设计时支持没有它dotnet ef migrations命令会报错。版本默认和 SDK 一致不需要额外指定。接着建应用上下文和连接字符串。打开appsettings.Development.json把数据库连接写好。{ ConnectionStrings: { DutyDb: Server(localdb)\\MSSQLLocalDB;DatabaseDutySystemDb;Trusted_ConnectionTrue;MultipleActiveResultSetstrue }, Logging: { LogLevel: { Default: Information } } }连接字符串有几个关键点MultipleActiveResultSetstrue是给 EF Core 懒加载或同一连接多个 DataReader 用的加上它能在某些场景避免诡异的运行时错误Trusted_ConnectionTrue表示用当前 Windows 账户登录单位内网部署时也可以改成 SQL Server 账号或集成身份到服务账号。然后在Program.cs里注册 DbContext。using Microsoft.EntityFrameworkCore; using DutySystem.Data; var builder WebApplication.CreateBuilder(args); builder.Services.AddRazorPages(); builder.Services.AddDbContextDutyContext(options options.UseSqlServer(builder.Configuration.GetConnectionString(DutyDb))); var app builder.Build(); if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler(/Error); app.UseHsts(); } app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); app.MapRazorPages(); app.Run();这段代码的作用是把 DbContext 注册到依赖注入容器后续每个页面的 PageModel 构造函数里直接注入DutyContext就能用。MapRazorPages()是 Razor Pages 的路由注册入口不需要手写控制器路由。下面创建数据库迁移这是整个项目第一次触碰数据库的步骤。dotnet ef migrations add InitDutySchema dotnet ef database update第一次跑dotnet ef database update时会自动创建数据库和表结构。如果此时报“未安装 Entity Framework Core 工具”一类的错误先执行dotnet tool install --global dotnet-ef。我在给用户做环境检查时80% 的报错都出在这条命令没装。3.2 登录与角色划分Cookie 认证的最小接入值班系统不需要搞复杂的单点登录ASP.NET Core 自带 Cookie 认证就够。用 Cookie 模式的原因很简单部署环境是内网没有 Azure AD 或第三方 OAuth 条件账号密码存在本地数据库表结构自己可控。Program.cs 里加上认证服务和中间件。builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) .AddCookie(options { options.LoginPath /Login; options.AccessDeniedPath /Forbidden; options.ExpireTimeSpan TimeSpan.FromHours(8); }); // 中间件顺序在 UseRouting 之后UseAuthorization 之前 app.UseAuthentication(); app.UseAuthorization();Cookie 认证的LoginPath是指未登录用户跳转的地址ExpireTimeSpan设置会话时长按值班系统的使用频率8 小时比较合适避免值班员第二天打开还要重新登录又觉得太麻烦。要注意中间件顺序UseAuthentication必须放在UseRouting之后、UseAuthorization之前放反了会直接导致登录页跳转不生效。登录页面做一个简单表单提交用户名密码后用PasswordHasher校验散列值通过后写出ClaimsPrincipal。var claims new ListClaim { new Claim(ClaimTypes.Name, user.DisplayName), new Claim(ClaimTypes.Role, user.IsAdmin ? Admin : User) }; var identity new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme); var principal new ClaimsPrincipal(identity); await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, principal);ClaimsPrincipal是 ASP.NET Core 里表示当前用户的载体登录成功后的用户身份信息都存在 Cookie 里后续每个页面用User.Identity.Name就能取到显示名。把角色丢进 Claim 里页面加[Authorize(Roles Admin)]特性就能控制后台权限。角色权限分配上我的习惯是排班管理页和审批操作只有 Admin 角色能访问普通值班员只能看自己的排班、提交换班申请。颗粒度到页面级别就够了不需要做细到按钮级别的权限控制否则维护成本会超过系统本身的价值。4. 排班核心逻辑循环排班、换班冲突、统计导出4.1 自动排班生成按规则生成一个月排班表日常值班系统最常见的是循环排班模式若干个人轮流值几个班次节假日或周末可能需要指定人员。排班算法不需要上什么“智能排班”的复杂模型用简单的轮值分配就能满足九成单位的需求。public async Task GenerateMonthlySchedule(int year, int month, Listint userIds) { var daysInMonth DateTime.DaysInMonth(year, month); var startDate new DateTime(year, month, 1); var existing await _context.ScheduleRecords .Where(r r.WorkDate.Year year r.WorkDate.Month month) .ToListAsync(); if (existing.Any()) throw new InvalidOperationException(本月已有排班不能重复生成); var rotations new Dictionaryint, int(); // userId - 轮次指针 for (int day 1; day daysInMonth; day) { var currentDate startDate.AddDays(day - 1); foreach (var shift in shifts) { // 跳过周末不安排早班只安排夜班 if (currentDate.DayOfWeek DayOfWeek.Saturday || currentDate.DayOfWeek DayOfWeek.Sunday) continue; // 从参与轮值的用户里取下一个 int userId PickNextUser(userIds, rotations); _context.ScheduleRecords.Add(new ScheduleRecord { UserId userId, ShiftId shift.Id, WorkDate currentDate, Status 0, CreatedAt DateTime.Now }); } } await _context.SaveChangesAsync(); }这个实现的逻辑说明开头先检查当月是否已存在排班数据避免重复生成把已有记录冲掉。rotations字典用于追踪每个班次的轮值指针PickNextUser每次都把数组下标往后移一位这样可以让同一人不会连续两晚值夜班。白天班次和夜班应用独立指针否则会出现同一个人白天晚上连轴转以我的经验这是一个非常常见的乌龙。实际项目里我会把PickNextUser写成独立的静态方法并且支持传入“排除名单”比如有人请假。运行前先统计一下当月夜班天数是否能被参与人数整除不能平均分时把多余的天数集中排在月末让系统行为可预测。4.2 换班申请与两段冲突检查换班是值班系统里最频繁的操作也是数据最容易乱的地方。换班的本质是两个人交换某一天的班次或者 A 把某天的班交给 B 代值。无论哪种形式核心都是检查要换的那一天是否冲突检查被换入的人当天是否已经有班次。public async Task(bool ok, string message) CheckSwap(int sourceRecordId, int targetUserId, DateTime targetDate) { var sourceRecord await _context.ScheduleRecords .Include(r r.Shift) .FirstOrDefaultAsync(r r.Id sourceRecordId); if (sourceRecord null) return (false, 原排班记录不存在); var targetRecord await _context.ScheduleRecords .FirstOrDefaultAsync(r r.UserId targetUserId r.WorkDate targetDate); if (targetRecord ! null targetRecord.Status 0) return (false, $目标用户 {targetDate:yyyy-MM-dd} 已值 {targetRecord.Shift.Name}); return (true, ); }冲突检查的细节targetRecord.Status 0表示目标用户该天有且状态正常的班次。如果状态是已换班说明原班次已经变更过了继续换会出现一条排班记录对应两条承诺的混乱。换班审批流通常是提交申请 → 管理员或对方确认 → 把双方的排班记录状态改成已换班同时各生成或调整一条新记录。整个过程用事务包住避免更新一半时服务重启造成数据一半新一半旧。await using var transaction await _context.Database.BeginTransactionAsync(); try { sourceRecord.Status 1; sourceRecord.UserId targetUserId; targetRecord.Status 1; targetRecord.UserId sourceRecord.UserId; await _context.SaveChangesAsync(); await transaction.CommitAsync(); } catch { await transaction.RollbackAsync(); throw; }这段事务代码里有个容易被忽视的细节SaveChangesAsync只会更新变更过的实体。因为上面代码直接改的是实体的UserId和Status没有新增记录所以不会产生重复。真正值得警惕的是并发场景两个管理员同时操作同一个换班对或者值班员自己提交换班时连续点了两次提交按钮这时事务不一定能挡住因为读到的快照都是旧值。我的做法是在排班表上加RowVersion乐观并发字段更新时 EF Core 会自动带上旧版本号比对版本不一致就抛DbUpdateConcurrencyException捕获后提示“请刷新后再试”。4.3 月统计与导出按人按月汇总值班数值班系统要持续用下去月底统计一定是高频功能。统计口径必须提前和业务方确认清楚通常有三个维度按人统计当月值班次数、按班次类型各值多少次、节假日值班单独列出来算补贴。返工的成本很高而这些口径就写在一屏里。public async TaskListDutyStatRow GetMonthlyStats(int year, int month) { var records await _context.ScheduleRecords .Include(r r.User) .Include(r r.Shift) .Where(r r.WorkDate.Year year r.WorkDate.Month month r.Status ! 2) .ToListAsync(); return records .GroupBy(r new { r.UserId, r.User.DisplayName }) .Select(g new DutyStatRow { DisplayName g.Key.DisplayName, TotalCount g.Count(), ShiftCounts g.GroupBy(r r.Shift.Name) .ToDictionary(x x.Key, x x.Count()) }) .OrderByDescending(r r.TotalCount) .ToList(); }注意r.Status ! 2这个条件意思是调休状态的不计入值班次数。已换班的状态为 1因为排班记录换了人统计逻辑上是算给新承接的人所以不能被过滤掉。这是最容易踩的统计口径坑如果直接查全部记录且没有排除掉换班前旧归属就会出现同一天两个人各算了一次值班月底对账时所有人总数比实际天数多。我在早期一个项目里就是没处理这一条和业务方对了一下午才发现是这里的问题。导出用CsvHelper这个库比较省事两行代码就能把统计结果转成 CSV 下载using var writer new StringWriter(); using var csv new CsvWriter(writer, CultureInfo.InvariantCulture); csv.WriteRecords(stats); return File(Encoding.UTF8.GetBytes(writer.ToString()), text/csv, $duty_stat_{year}_{month}.csv);导出时注意中文 CSV 在 Excel 里打开乱码的问题解决方式是在文件开头写 BOM 头。var bytes Encoding.UTF8.GetPreamble() .Concat(Encoding.UTF8.GetBytes(csvText)) .ToArray();5. 值班系统常见问题排查五条影响上线的避坑记录5.1 进程挂起后无人自动检查定时任务没落地的后果现象排班生成功能上线后管理员每天早上手动点一次生成当日排班但偶尔忘记点当天值班表就是空的。时间长了大家不信任系统又回到微信群口头沟通。原因系统里没有定时任务机制生成的逻辑只存在于手动点击的页面处理中。值班系统本质上需要一个后台任务在固定时间自动执行比如每天凌晨 2 点生成未来 7 天的滚动排班。解决在 ASP.NET Core 里用IHostedService做后台定时服务注册为单例用PeriodicTimer控制触发频率。public class ScheduleBackgroundService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory; private readonly TimeSpan _interval TimeSpan.FromHours(24); public ScheduleBackgroundService(IServiceScopeFactory scopeFactory) { _scopeFactory scopeFactory; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { using var timer new PeriodicTimer(_interval); while (!stoppingToken.IsCancellationRequested) { await EnsureScheduleGeneratedAsync(); await timer.WaitForNextTickAsync(stoppingToken); } } private async Task EnsureScheduleGeneratedAsync() { using var scope _scopeFactory.CreateScope(); var context scope.ServiceProvider.GetRequiredServiceDutyContext(); // 检查未来 7 天是否已有排班没有则补生成 } }IServiceScopeFactory的关键性后台服务是单例但 DbContext 是 scoped 生命周期直接在构造函数注入DutyContext会造成单例持有 scoped 对象导致资源释放问题。每次执行时用CreateScope()新建一个作用域这是 ASP.NET Core 后台任务的标准做法。5.2 换班申请提交后对方看不到数据状态链路没打通现象值班员 A 提交换班申请系统提示成功但值班员 B 的待办列表里没有这条申请。原因申请提交时只写了SwapRequest表的一条记录但列表查询时过滤条件用的是TargetUserId 当前用户Id提交时没有把 B 的 ID 写进申请表的TargetUserId字段而是存了 A 自己的 ID。解决提交申请时明确区分“申请人”与“被请求人”两个字段列表查询时查TargetUserId currentUserId Status Pending。同时加一个索引(TargetUserId, Status)避免待办列表页数据量大时变慢但值班系统数据量小这个索引更多是规范意义。5.3 排班显示的时间总是差 8 小时时区存储的坑现象管理员在页面上看到值班日期是 2024-06-01但数据库里存的变成 2024-05-31 16:00:00 或反过来。导出报表时日期全乱了。原因数据库连接串里没有指定时区处理EF Core 在读写DateTime时按应用本地时区转换而服务器的系统时区如果设置成了 UTC就会产生偏移。ASP.NET Core 部署后默认按服务器系统时区解释开发机和服务器时区不一致同一份代码两端表现不同。解决排班表里所有日期字段统一用DateOnly类型WorkDate只存日期整数概念不涉及时区转换。public DateOnly WorkDate { get; set; }如果不想引入DateOnly有些老版本 EF Core 映射支持不完善退而求其次用DateTime但统一约定存 UTC 并在读取时用DateTime.SpecifyKind指定为Unspecified页面展示时用ToString(yyyy-MM-dd)忽略时间部分。5.4 自动排班陷入死循环参与人数与班次天数不匹配现象排班生成任务偶尔卡死日志里看到GenerateMonthlySchedule方法被反复调用服务器 CPU 飙升。原因PickNextUser方法里没有判断用户列表是否为空当排班排除名单把所有参与人都移除后数组越界又没被捕获外层循环挂起重试。解决在方法入口处加人数检查参与人数小于 2 时直接拒绝生成并打出明确错误日志。if (userIds.Count 2) throw new InvalidOperationException(参与排班人数不足 2 人无法生成排班);还有一个隐蔽情况早班只在工作日排夜班天天排夜班人数足够但早班参与人只有 1 人早班的轮值逻辑正常但夜班的排除名单可能把所有人都排除了。正确做法是每个班次的参与人单独维护共用同一批人但不排除特定班次时人数为 0。5.5 导出 CSV 后 Excel 打开中文乱码编码问题现象导出统计文件后用 Excel 打开 CSV汉字变成乱码数字和日期正常。原因CsvWriter 默认用无 BOM 的 UTF-8 输出Excel 用系统本地编码解析在中文系统上默认按 ANSI 即 GBK 解析导致编码不匹配。解决在输出字节前手动把 BOM 带上这条在 4.3 节已经给出代码。这也是一个经典血泪经验开发环境用 Visual Studio Code 预览没问题但用户的电脑是默认安装的 Excel这就是环境差异带来的“看起来没问题客户手里翻车”。6. 值班系统的进阶技巧交接班记录怎么落地最有价值排班数据跑通后最有价值的功能不是生成排班表而是交接班记录。值班员交班时把当班情况、待办事项、设备异常写成一条记录下一班的人登录就能看到。这个功能能把值班系统的价值从“电子表格”升级为“信息交接平台”单位里的认可度会明显提升。交接班记录最简单的数据结构是主表和明细表主表记录哪个班次、交班人、接班人、交接时间明细表记录若干条文字条目比如“大厅灯管坏了”“访客登记本用完”“服务器重启完成”。明细表用 JSON 存也不是不行但后续做关键词搜索就不方便所以还是正规化成子表更合理。public class HandoverRecord { public int Id { get; set; } public int ScheduleId { get; set; } public int FromUserId { get; set; } public int ToUserId { get; set; } public DateTime HandoverTime { get; set; } public string NotesJson { get; set; } }我一般会把提交页做成一个动态行编辑器交班人逐条输入页面上用 JavaScript 动态增删行提交时序列化成一个 JSON 数组存到NotesJson。这个字段在 SQL Server 里映射为nvarchar(max)读取时反序列化即可不需要引入专门的 JSON 列类型兼容性更好。关于验证系统上线后建议每周做一次数据一致性检查重点查三类数据换班后是否有排班记录状态还是 0 导致统计重复同一用户同一天是否有两条排班记录节假日排班是否漏排。可以写成一个独立页面输出异常列表也可以直接写 SQL 脚本定时跑。SELECT r1.UserId, r1.WorkDate FROM ScheduleRecords r1 JOIN ScheduleRecords r2 ON r1.UserId r2.UserId AND r1.WorkDate r2.WorkDate AND r1.ShiftId r2.ShiftId AND r1.Id r2.Id;这种自查脚本比任何单元测试都直接我习惯把它集成发版前检查的一部分。部署和备份的进阶建议也放在这里排班数据量不大但它是业务数据备份不能少。SQL Server Express 自带维护计划不好用我一般写一个 Windows 计划任务每天凌晨用sqlcmd做一次数据库备份保留最近 30 天。sqlcmd -S .\SQLEXPRESS -Q BACKUP DATABASE DutySystemDb TO DISKD:\Backup\Duty_$(date %Y%m%d).bak -E最终一条素养值班系统是给人用的所有流程设计都要站在值班员角度来看。功能越多不一定越好把排班、换班、交接、统计这四条主链路做扎实比堆砌轮播图和大屏仪表盘有用得多。我自己做这类系统的习惯就是——先让管理员用着顺手再让值班员用着省心最后才考虑数据大屏。希望这篇内容能帮到你少踩几个我之前踩过的坑。本文还有配套的精品资源点击获取