简介一套面向企事业单位值班管理场景的ASP.NET WebForms源码项目基于Visual Studio 2010与Access数据库开发包含登录认证、值班排班、部门与人员维护、历史值班查询、离岗登记等常用功能适合需要快速搭建轻量级B/S值班系统的开发者参考。压缩包共77个文件约8.39MB主体为31个aspx页面、2个ascx用户控件配合CSS样式表、JavaScript脚本含jQuery、日期选择器、少量DLL程序集及MDB数据库文件另含帮助说明文本与环境配置文件便于还原初始运行状态页面、脚本、图片、数据分层存放便于按模块查找与二次开发。目前已有491人学习下载说明该案例具备一定的通用性与借鉴价值。通过它可学习ASP.NET页面事件处理、用户控件复用、Ajax局部刷新、Access数据库操作以及值班排班逻辑的实现细节对入门ASP.NET或承担行政办公类小型管理系统开发工作具有参考意义。1. 值班排班还在用ExcelASP.NET值班管理系统把这一摊子搬进浏览器在很多单位值班排班至今还是三张Excel表一张排班、一张换班记录、一张月末统计月末对着微信群里的截图核对能核对到晚上十点。ASP.NET值班管理系统就是把这一摊子搬进浏览器ASPX页面管排班、换班申请、审批、值班记录和统计数据库统一存权限按角色分。它不追求技术新WebForms的Postback模型放给老同事用反而顺手IIS一挂就能用。适合的场景很明确——车间班组、医院科室、物业保安这类要按周/月循环排班、审批留痕的团队以及手里还攥着旧ASP.NET代码想快速整改交付的开发者。老技术不代表该被淘汰在内部管理系统这个圈子里稳定、好维护、不容易跑偏比炫技重要得多。2. ASP.NET WebForms值班系统的家底三层架构与五张核心表2.1 为什么这个场景还选ASPX生命周期、Postback与ViewState很多新入场的开发者一看到ASPX就皱眉觉得是历史包袱。在这个项目场景里选型恰恰是被需求推着走的第一改动范围就是内部局域网一台服务器带几十个并发第二业务逻辑是典型的表单列表审批Postback天然契合第三团队里老员工熟悉的是GridView绑定数据这样直白的写法上手快不用重新培训。WebForms把状态管理交给ViewState服务器控件自带事件回发排班页面选中一行、点击换班事件的触发和值传递都封装在页面生命周期里这一点和MVC的路由与控制器模型完全是两套心智。ASPX页面的生命周期大致是请求进来后依次触发Init、Load、事件处理、PreRender、SaveState、Render。Init阶段恢复控件树Load阶段加载数据事件处理阶段响应按钮点击或行命令。新手最容易犯的错是忘了判断IsPostBack导致每次回发都重新绑定数据用户改了一半的表单被刷新掉。值班系统里排班页、换班审批页都频繁发生回发所以Page_Load里绑数据的逻辑必须用if (!IsPostBack)包住这个习惯比任何框架技巧都重要。2.2 五张核心表从排班计划到换班审批的数据模型这套值班系统的数据库我拆成了五张核心表分别是用户表、班次表、排班计划表、换班申请表和值班记录表。用户表管登录和角色班次表管白班夜班的起止时间排班计划表是业务主表换班申请表管审批流值班记录表存每次值班的交接内容。拆表的原则是班次这种会重复引用的字典数据必须独立成表不然排班计划里时间写死后面统计夜班次数会写得非常痛苦。CREATE TABLE DutyUser ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(20) NOT NULL, RoleId INT NOT NULL, -- 1管理员 2排班员 3普通值班员 IsEnabled BIT NOT NULL DEFAULT 1 ); CREATE TABLE DutyShift ( ShiftId INT IDENTITY(1,1) PRIMARY KEY, ShiftName NVARCHAR(20) NOT NULL, -- 白班/夜班 StartTime NVARCHAR(5) NOT NULL, -- 08:00 EndTime NVARCHAR(5) NOT NULL -- 20:00 ); CREATE TABLE DutyPlan ( PlanId INT IDENTITY(1,1) PRIMARY KEY, UserId INT NOT NULL, DutyDate DATE NOT NULL, ShiftId INT NOT NULL, Status TINYINT NOT NULL DEFAULT 0 -- 0正常 1已换班 2已调休 ); CREATE TABLE DutySwap ( SwapId INT IDENTITY(1,1) PRIMARY KEY, PlanIdA INT NOT NULL, -- 发起人的排班ID PlanIdB INT NOT NULL, -- 被换班人的排班ID Reason NVARCHAR(200) NULL, Status TINYINT NOT NULL DEFAULT 0 -- 0待审批 1同意 2拒绝 ); CREATE TABLE DutyLog ( LogId INT IDENTITY(1,1) PRIMARY KEY, PlanId INT NOT NULL, -- 关联到排班计划 Content NVARCHAR(500) NOT NULL, -- 值班交接事项 CreatedTime DATETIME NOT NULL DEFAULT GETDATE() );Why 这样设计DutyShift把班次单独拆出来加一个新班次不需要改排班表结构统计报表里按ShiftName聚合也很顺DutyPlan里DutyDate用DATE类型而非DATETIME是为了避免排班日期被时间部分污染DutySwap只存两边的排班计划ID不冗余值班人姓名审批通过后直接改DutyPlan的状态换班记录天然留痕。这套表结构不复杂但覆盖了排班、换班、记录、统计四条主要业务线。2.3 列表页的标准姿势GridView 分页 RowCommand值班系统的列表页面无论是排班计划列表还是值班记录列表常规做法都是GridView绑定数据配分页和行命令。下面这段代码是这个资源包里排班列表页的核心骨架把DataSource换成你自己的查询方法就能用。asp:GridView IDgrdPlan runatserver AutoGenerateColumnsFalse AllowPagingTrue PageSize20 OnPageIndexChanginggrdPlan_PageIndexChanging OnRowCommandgrdPlan_RowCommand Columns asp:BoundField DataFieldDutyDate HeaderText值班日期 DataFormatString{0:yyyy-MM-dd} / asp:BoundField DataFieldUserName HeaderText值班人 / asp:BoundField DataFieldShiftName HeaderText班次 / asp:ButtonField Text申请换班 CommandNameApplySwap ButtonTypeLinkButton / /Columns /asp:GridViewprotected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { BindPlan(1); } } private void BindPlan(int pageIndex) { // 分页参数最多只取当前页的数据避免全表加载 DataTable dt GetDutyPlanByPage(pageIndex, 20); grdPlan.DataSource dt; grdPlan.DataBind(); } protected void grdPlan_RowCommand(object sender, GridViewCommandEventArgs e) { if (e.CommandName ApplySwap) { int planId Convert.ToInt32(e.CommandArgument); // 跳到换班申请页把排班ID带过去 Response.Redirect(SwapApply.aspx?planId planId); } }逻辑说明Page_Load里只做首次绑定回发时GridView会把数据从ViewState里恢复不需要重新查库RowCommand通过CommandName区分操作类型CommandArgument这个参数在GridView里绑定的是当前行的主键。很多项目把GridView和后端代码耦合得很死建议封装一个GetDutyPlanByPage方法里面用SqlDataAdapter做分页查询这样列表页改动时只动一个方法页面事件可以保持干净。3. 排班与换班审批怎么落地生成规则、状态机与统计查询3.1 批量生成排班按固定规则生成一个月计划排班是最容易产生脏数据的环节。这个资源里的做法是先用存储过程按规则生成当月计划再允许排班员手工微调避免每天手打排班。常见规则是周一到周五白班、周末夜班人员按用户表顺序轮转。下面这个存储过程生成指定年月的排班计划参数只有两个年份和月份。CREATE PROCEDURE sp_GenerateDutyPlan Year INT, Month INT AS BEGIN SET NOCOUNT ON; SET XACT_ABORT ON; BEGIN TRAN; DECLARE StartDate DATE DATEFROMPARTS(Year, Month, 1); DECLARE EndDate DATE EOMONTH(StartDate); -- 重新生成前先清掉当月旧计划避免重复数据 DELETE FROM DutyPlan WHERE DutyDate BETWEEN StartDate AND EndDate; ;WITH Numbers AS ( SELECT 0 AS n UNION ALL SELECT n 1 FROM Numbers WHERE n 31 ), DaysOfMonth AS ( SELECT DATEADD(DAY, n, StartDate) AS DutyDate FROM Numbers WHERE DATEADD(DAY, n, StartDate) EndDate ) INSERT INTO DutyPlan (UserId, DutyDate, ShiftId, Status) SELECT u.UserId, d.DutyDate, CASE WHEN DATEPART(WEEKDAY, d.DutyDate) IN (1, 7) THEN 2 ELSE 1 END AS ShiftId, 0 AS Status FROM DaysOfMonth d CROSS JOIN ( SELECT TOP 10 UserId FROM DutyUser WHERE IsEnabled 1 ORDER BY UserId ) u; COMMIT; END参数说明Year、Month决定生成哪个月DATEFROMPARTS拼出月初日期EOMONTH算出月末Numbers递归CTE生成1号到月底的所有日期最大31天够用CROSS JOIN把每个日期和值班用户做笛卡尔积再用DATEPART(WEEKDAY)判断周末。这里有个坑DATEPART(WEEKDAY)的结果受SET DATEFIRST影响默认周日是1周一是2如果你改了DATEFIRST判断逻辑要跟着调。注意这个写法适合人数不超过10人的小团队人数多了会出现同一天排给多人的情况实际项目里一般会在规则层再加一个人数过滤或者轮转序号。CROSS JOIN的轮转顺序是按UserId排的要改成按上次值班日期轮转得在存储过程里加一个排序号字段这个可以放到后期功能里再补。3.2 换班申请与审批状态机 唯一性校验换班是值班系统里最容易产生数据冲突的地方。A和B换班如果两边都同时操作就可能出现一条排班记录被换走两次的情况。这个资源把审批逻辑放在存储过程里事务内做校验能有效避免并发窗口。protected void grdPlan_RowCommand(object sender, GridViewCommandEventArgs e) { if (e.CommandName ApplySwap) { int sourcePlanId Convert.ToInt32(e.CommandArgument); // 把来源排班ID放到ViewState审批页提交时再取 ViewState[SourcePlanId] sourcePlanId; Response.Redirect(SwapApply.aspx?planId sourcePlanId); } }换班申请页填好对方排班ID和理由之后提交时调用审批存储过程。审批时最关键的是下面这段状态校验CREATE PROCEDURE sp_AuditSwap SwapId INT, Status TINYINT AS BEGIN SET NOCOUNT ON; DECLARE PlanA INT, PlanB INT; -- 取出换班申请两边的排班ID SELECT PlanA PlanIdA, PlanB PlanIdB FROM DutySwap WHERE SwapId SwapId; IF Status 1 BEGIN -- 校验两条排班都是正常状态任何一条已换过就不能再换 IF EXISTS ( SELECT 1 FROM DutyPlan WHERE PlanId IN (PlanA, PlanB) AND Status 0 ) BEGIN RAISERROR(其中一条排班已经参与过换班不能重复操作, 16, 1); RETURN; END -- 两边的状态同时改成已换班 UPDATE DutyPlan SET Status 1 WHERE PlanId PlanA; UPDATE DutyPlan SET Status 1 WHERE PlanId PlanB; UPDATE DutySwap SET Status 1 WHERE SwapId SwapId; END ELSE BEGIN -- 拒绝只更新申请状态排班计划保持原样 UPDATE DutySwap SET Status 2 WHERE SwapId SwapId; END END逻辑说明存储过程先把待审申请的两个排班ID取出来通过判断DutyPlan.Status是否等于0来保证排班记录没被换过两条排班同时更新状态要么都成功要么都失败事务保证一致性。应用层校验最大的问题是两条SQL语句之间存在时间差理论上会出现两边同时读到Status0然后都执行更新存储过程把查询和更新放在同一个事务批次里风险小得多。3.3 值班记录与统计报表聚合查询与导出兜底值班记录页就是值班人登录后按排班日期写交接内容一张表单提交后写入DutyLog。统计报表则用聚合SQL一个月跑一次直接给管理员的页面出数据。下面是最常用的每人值班数统计统计某个月的每人总值班次数、夜班次数和换班次数。SELECT u.UserName, COUNT(*) AS TotalDuty, SUM(CASE WHEN s.ShiftName N夜班 THEN 1 ELSE 0 END) AS NightDuty, SUM(CASE WHEN p.Status 1 THEN 1 ELSE 0 END) AS SwapCount FROM DutyPlan p JOIN DutyUser u ON u.UserId p.UserId JOIN DutyShift s ON s.ShiftId p.ShiftId WHERE p.DutyDate BETWEEN StartDate AND EndDate GROUP BY u.UserName ORDER BY TotalDuty DESC;参数说明StartDate和EndDate是统计区间的起止日期传当月第一天和最后一天。SUM(CASE WHEN ...)是聚合里常用的条件计数写法比COUNT加WHERE再拼接多个结果集方便得多。排序用TotalDuty DESC可以让值班次数多的人排前面方便管理员一眼看出工作量不平衡。报表页面我一般会再加一个月份选择器选中后往这个SQL传两个日期参数整个报表页不需要接第三方图表库直接用GridView渲染出来就行。4. 部署与配置IIS、连接串与目录权限三件套4.1 Web.config连接串与发布方式老项目的连接串经常是明文写在Web.config里的而且要改IP、账号、密码还要改配置文件里的整段字符串。建议把这个资源包里的连接串单独抽到connectionStrings节点里发布时只改这一处不用在代码里到处找SQL连接。connectionStrings add nameDutyConn connectionStringData Source127.0.0.1;Initial CatalogDutyDB;User IDduty_user;Passwordxxxx;MultipleActiveResultSetsTrue; providerNameSystem.Data.SqlClient / /connectionStrings参数说明Data Source是数据库实例地址Initial Catalog是数据库名MultipleActiveResultSetsTrue允许在同一个连接上同时执行多个查询排班页面里同时读取列表和统计时能减少连接占用。如果服务器是Windows认证方式连接串可以改成Integrated SecurityTrue。要注意的是密码里如果包含分号、引号这类特殊字符必须用XML实体转义不然配置文件直接解析失败。发布方式上老项目常用“发布网站”直接拷到服务器aspx文件保留源码改动页面比较方便预编译发布会把所有C#代码编译成DLL服务器上看不到后台代码。两种方式对值班系统来说都够用但如果接的是外包活我一般选预编译防止源码泄露。发布方式服务器上是否保留aspx源码适合场景发布网站保留页面可改内部运维、频繁微调预编译只留编译后的DLL交付外包、代码保护4.2 IIS应用池与身份部署到IIS时新手最容易翻车的点是应用池没配对页面一打开就报503或者无法识别的错误。值班系统的页面是基于WebForms的应用池的.NET CLR版本要选v4.0托管管道模式建议用集成模式。经典模式下有些控件事件和控制器的处理方式不同跑起来会出现诡异的页面行为排查半天才发现是管道模式不对。配置项建议值说明.NET CLR版本v4.0对应.NET Framework 4.x托管管道模式集成模式与模块、授权协同更顺应用程序池标识ApplicationPoolIdentity默认即可权限隔离创建完应用池后网站绑定里把主机头设置成内网机器名或IP端口可以用80也可以单独指定一个像8080这样的端口。如果服务器上已经跑了别的站点端口别冲突否则站点一直处于停止状态日志里不报错很难定位。4.3 文件目录权限与上传目录值班系统如果做了交接班图片上传IIS进程就需要对上传目录有写权限。默认的ApplicationPoolIdentity权限很有限直接往站点目录里写文件会报“对路径的访问被拒绝”。解决办法是在服务器上把上传目录的写权限显式授给当前应用池的虚拟账号命令可以这样敲icacls D:\DutySite\Uploads /grant IIS APPPOOL\DutyPool:(CI)(OI)M参数说明D:\DutySite\Uploads是上传目录的物理路径DutyPool是应用池名称(CI)(OI)表示容器和对象都继承这个权限M是修改权限比完全控制少一点够用。跑完命令后最好手动在浏览器里传一张图试试能传上去说明权限通了。日志目录也是一样Global.asax里写文件日志的路径需要IIS用户有写权限否则异常记录写不进去后面排错就没有依据。5. 值班系统常见的坑与排查五条翻车记录5.1 线上报错但日志文件一片空白现象用户点“生成排班”后页面直接报黄页错误管理员打开服务器上的日志文件却发现一个字都没有。原因很多老项目只在页面里捕获了异常没有在应用层面统一记录异常一旦发生在存储过程调用或事件绑定里就直接抛到页面层日志系统没接到。解决在Global.asax里加Application_Error事件把还活着的异常抓下来写入日志文件。protected void Application_Error(object sender, EventArgs e) { Exception ex Server.GetLastError(); string logPath Server.MapPath(~/Logs/error_ DateTime.Now.ToString(yyyyMMdd) .log); System.IO.File.AppendAllText(logPath, DateTime.Now.ToString(yyyy-MM-dd HH:mm:ss) ex.ToString() Environment.NewLine); Server.ClearError(); }逻辑说明App_Data或Logs目录需要IIS写权限这段代码里文件路径按天拆开方便按日期翻问题。抓到异常后调用Server.ClearError()是为了防止它继续往后抛造成二次报错。从那之后我每接一个老项目第一件事就是确认全局异常日志能不能写进去不然排查问题等于摸黑。5.2 排班页面刷新后数据丢失现象管理员在排班页调好了几行数据一按F5刚填的内容全没了提示重新登录。原因Session默认是InProc模式存在IIS进程内应用池一旦回收所有登录状态和页面暂存数据全部消失。解决让Session不依赖应用池进程改用StateServer或SQL Server存Session如果不想改架构至少在排班这种关键页面把暂存数据写进数据库不能在Session里留关键业务数据。常见的状态配置是在Web.config的system.web节点里加sessionState模式整套值班系统如果只是内部几十个人用StateServer就够了。5.3 连接池耗尽导致登录超时现象系统运行一两个月后某天早上所有人登录都报“Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool”。原因有人写数据访问代码时只Open不Close或者用了DataTable但没有释放DataAdapter关联的连接连接池的连接全部被占满。解决把所有SqlConnection改成using块包裹确保方法结束或异常时连接释放。// 反面只new不释放 SqlConnection conn new SqlConnection(connStr); conn.Open(); // 正面using块保证Dispose using (SqlConnection conn new SqlConnection(connStr)) { conn.Open(); using (SqlCommand cmd new SqlCommand(sql, conn)) { // 执行查询 } }参数说明连接池默认开启Max Pool Size默认是100这个数值不是越大越好池只是复用连接不是无限开连接。修完代码后重启应用池连接池会被清空之后再观察一两个月超时一般就再没出现过。5.4 部署后CSS和图片全部404现象本地开发一切正常发布到IIS后页面裸奔样式全丢图片也打不开。原因aspx页面里用了相对路径引用CSS比如css/style.css当页面处在子目录或虚拟目录下时相对路径变成了子目录下的cssIIS自然找不到。解决统一用根路径或ResolveUrl生成绝对路径模板页里的写法是这样link href% ResolveUrl(~/Content/site.css) % relstylesheet /逻辑说明~会解析到当前站点的根路径ResolveUrl拿到的是完整的应用程序根路径无论在哪个子目录都能正确指到Content/site.css。这个坑在本地调试时不容易出现因为本地路径和最终部署路径一致只有部署到虚拟目录或子目录时才暴露。5.5 日期又少了一天UTC与格式化现象值班记录页显示的日期是前一天或者Excel导出里日期变成了带时间的乱码。原因数据库里存的字段是DATETIME带时分秒页面绑定GridView时没有指定格式化字符串默认把2025-03-15 00:00:00整个输出另外如果服务器Region设为UTC而C#代码里用了ToLocalTime会出现差一天。解决排班日期字段在表里就用DATE类型页面显示统一用DataFormatString{0:yyyy-MM-dd}取数据时用Convert.ToDateTime转完再ToString格式化不要拿着DataRow里的值直接ToString。// 错误item[DutyDate]是object直接ToString输出完整时间 object rawDate row[DutyDate]; string bad rawDate.ToString(); // 正确先转DateTime再格式化 string good Convert.ToDateTime(rawDate).ToString(yyyy-MM-dd);逻辑说明Convert.ToDateTime会根据服务器区域设置解析如果服务器是UTC时区和数据库本地时间会有偏差。内部系统最稳妥的做法是不做时区转换数据库存什么就显示什么统一格式字符串所有列表、报表、导出Excel都用同一个格式日期类问题基本能根治。6. 进阶改造统一鉴权、字典缓存与报表导出6.1 统一鉴权所有页面继承一个BasePage老值班系统的登录校验经常散落在每个页面的Page_Load里代码重复且容易漏。一个有效做法是新增一个BasePage类让所有业务页面继承它在OnInit阶段判断登录状态。public class BasePage : System.Web.UI.Page { protected int CurrentUserId { get; private set; } protected override void OnInit(EventArgs e) { if (Session[UserId] null) { Response.Redirect(~/Login.aspx?returnUrl Server.UrlEncode(Request.RawUrl)); } CurrentUserId (int)Session[UserId]; base.OnInit(e); } }OnInit比Load早登录失效时能第一时间跳走带returnUrl参数可以让用户登录后回到原页面。6.2 字典缓存班次数据不每次查库班次表这种基本不变的字典数据每次打开排班页都查库属于白白消耗连接。我一般会在数据访问层套一个Cache缓存首次读取后缓存30分钟管理员调整班次后手动清缓存。private DataTable GetShifts() { if (Cache[DictShift] null) { // 从数据库加载班次表 Cache.Insert(DictShift, dt, null, DateTime.Now.AddMinutes(30), TimeSpan.Zero); } return (DataTable)Cache[DictShift]; }缓存过期时间设成30分钟一个周期数据变化后最多延迟半小时生效内部系统完全够用。6.3 报表导出不引入第三方库的Excel方案统计报表要导出Excel老服务器不一定连外网不方便装NuGet包。经验做法是直接输出HTML表格并声明Excel的ContentType中文导出不乱码的关键是编码设成GB2312。Response.Clear(); Response.ContentType application/vnd.ms-excel; Response.ContentEncoding Encoding.GetEncoding(GB2312); Response.AddHeader(Content-Disposition, attachment;filenameDutyReport.xls); Response.Write(tabletrtd值班人/tdtd值班次数/td/tr); Response.Write(/table); Response.End();这种方式生成的报表用Excel和WPS都能打开适合报表量不大、格式简单的场景。从那以后我每次维护这类型的老系统都强制走一遍先确认全局异常日志能写再检查Session过期策略最后盯一遍上传目录权限。旧系统不是不能动而是每一步都要给后来的人留好后悔药。希望帮到你。本文还有配套的精品资源点击获取
简介一套面向企事业单位值班管理场景的ASP.NET WebForms源码项目基于Visual Studio 2010与Access数据库开发包含登录认证、值班排班、部门与人员维护、历史值班查询、离岗登记等常用功能适合需要快速搭建轻量级B/S值班系统的开发者参考。压缩包共77个文件约8.39MB主体为31个aspx页面、2个ascx用户控件配合CSS样式表、JavaScript脚本含jQuery、日期选择器、少量DLL程序集及MDB数据库文件另含帮助说明文本与环境配置文件便于还原初始运行状态页面、脚本、图片、数据分层存放便于按模块查找与二次开发。目前已有491人学习下载说明该案例具备一定的通用性与借鉴价值。通过它可学习ASP.NET页面事件处理、用户控件复用、Ajax局部刷新、Access数据库操作以及值班排班逻辑的实现细节对入门ASP.NET或承担行政办公类小型管理系统开发工作具有参考意义。1. 值班排班还在用ExcelASP.NET值班管理系统把这一摊子搬进浏览器在很多单位值班排班至今还是三张Excel表一张排班、一张换班记录、一张月末统计月末对着微信群里的截图核对能核对到晚上十点。ASP.NET值班管理系统就是把这一摊子搬进浏览器ASPX页面管排班、换班申请、审批、值班记录和统计数据库统一存权限按角色分。它不追求技术新WebForms的Postback模型放给老同事用反而顺手IIS一挂就能用。适合的场景很明确——车间班组、医院科室、物业保安这类要按周/月循环排班、审批留痕的团队以及手里还攥着旧ASP.NET代码想快速整改交付的开发者。老技术不代表该被淘汰在内部管理系统这个圈子里稳定、好维护、不容易跑偏比炫技重要得多。2. ASP.NET WebForms值班系统的家底三层架构与五张核心表2.1 为什么这个场景还选ASPX生命周期、Postback与ViewState很多新入场的开发者一看到ASPX就皱眉觉得是历史包袱。在这个项目场景里选型恰恰是被需求推着走的第一改动范围就是内部局域网一台服务器带几十个并发第二业务逻辑是典型的表单列表审批Postback天然契合第三团队里老员工熟悉的是GridView绑定数据这样直白的写法上手快不用重新培训。WebForms把状态管理交给ViewState服务器控件自带事件回发排班页面选中一行、点击换班事件的触发和值传递都封装在页面生命周期里这一点和MVC的路由与控制器模型完全是两套心智。ASPX页面的生命周期大致是请求进来后依次触发Init、Load、事件处理、PreRender、SaveState、Render。Init阶段恢复控件树Load阶段加载数据事件处理阶段响应按钮点击或行命令。新手最容易犯的错是忘了判断IsPostBack导致每次回发都重新绑定数据用户改了一半的表单被刷新掉。值班系统里排班页、换班审批页都频繁发生回发所以Page_Load里绑数据的逻辑必须用if (!IsPostBack)包住这个习惯比任何框架技巧都重要。2.2 五张核心表从排班计划到换班审批的数据模型这套值班系统的数据库我拆成了五张核心表分别是用户表、班次表、排班计划表、换班申请表和值班记录表。用户表管登录和角色班次表管白班夜班的起止时间排班计划表是业务主表换班申请表管审批流值班记录表存每次值班的交接内容。拆表的原则是班次这种会重复引用的字典数据必须独立成表不然排班计划里时间写死后面统计夜班次数会写得非常痛苦。CREATE TABLE DutyUser ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(20) NOT NULL, RoleId INT NOT NULL, -- 1管理员 2排班员 3普通值班员 IsEnabled BIT NOT NULL DEFAULT 1 ); CREATE TABLE DutyShift ( ShiftId INT IDENTITY(1,1) PRIMARY KEY, ShiftName NVARCHAR(20) NOT NULL, -- 白班/夜班 StartTime NVARCHAR(5) NOT NULL, -- 08:00 EndTime NVARCHAR(5) NOT NULL -- 20:00 ); CREATE TABLE DutyPlan ( PlanId INT IDENTITY(1,1) PRIMARY KEY, UserId INT NOT NULL, DutyDate DATE NOT NULL, ShiftId INT NOT NULL, Status TINYINT NOT NULL DEFAULT 0 -- 0正常 1已换班 2已调休 ); CREATE TABLE DutySwap ( SwapId INT IDENTITY(1,1) PRIMARY KEY, PlanIdA INT NOT NULL, -- 发起人的排班ID PlanIdB INT NOT NULL, -- 被换班人的排班ID Reason NVARCHAR(200) NULL, Status TINYINT NOT NULL DEFAULT 0 -- 0待审批 1同意 2拒绝 ); CREATE TABLE DutyLog ( LogId INT IDENTITY(1,1) PRIMARY KEY, PlanId INT NOT NULL, -- 关联到排班计划 Content NVARCHAR(500) NOT NULL, -- 值班交接事项 CreatedTime DATETIME NOT NULL DEFAULT GETDATE() );Why 这样设计DutyShift把班次单独拆出来加一个新班次不需要改排班表结构统计报表里按ShiftName聚合也很顺DutyPlan里DutyDate用DATE类型而非DATETIME是为了避免排班日期被时间部分污染DutySwap只存两边的排班计划ID不冗余值班人姓名审批通过后直接改DutyPlan的状态换班记录天然留痕。这套表结构不复杂但覆盖了排班、换班、记录、统计四条主要业务线。2.3 列表页的标准姿势GridView 分页 RowCommand值班系统的列表页面无论是排班计划列表还是值班记录列表常规做法都是GridView绑定数据配分页和行命令。下面这段代码是这个资源包里排班列表页的核心骨架把DataSource换成你自己的查询方法就能用。asp:GridView IDgrdPlan runatserver AutoGenerateColumnsFalse AllowPagingTrue PageSize20 OnPageIndexChanginggrdPlan_PageIndexChanging OnRowCommandgrdPlan_RowCommand Columns asp:BoundField DataFieldDutyDate HeaderText值班日期 DataFormatString{0:yyyy-MM-dd} / asp:BoundField DataFieldUserName HeaderText值班人 / asp:BoundField DataFieldShiftName HeaderText班次 / asp:ButtonField Text申请换班 CommandNameApplySwap ButtonTypeLinkButton / /Columns /asp:GridViewprotected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { BindPlan(1); } } private void BindPlan(int pageIndex) { // 分页参数最多只取当前页的数据避免全表加载 DataTable dt GetDutyPlanByPage(pageIndex, 20); grdPlan.DataSource dt; grdPlan.DataBind(); } protected void grdPlan_RowCommand(object sender, GridViewCommandEventArgs e) { if (e.CommandName ApplySwap) { int planId Convert.ToInt32(e.CommandArgument); // 跳到换班申请页把排班ID带过去 Response.Redirect(SwapApply.aspx?planId planId); } }逻辑说明Page_Load里只做首次绑定回发时GridView会把数据从ViewState里恢复不需要重新查库RowCommand通过CommandName区分操作类型CommandArgument这个参数在GridView里绑定的是当前行的主键。很多项目把GridView和后端代码耦合得很死建议封装一个GetDutyPlanByPage方法里面用SqlDataAdapter做分页查询这样列表页改动时只动一个方法页面事件可以保持干净。3. 排班与换班审批怎么落地生成规则、状态机与统计查询3.1 批量生成排班按固定规则生成一个月计划排班是最容易产生脏数据的环节。这个资源里的做法是先用存储过程按规则生成当月计划再允许排班员手工微调避免每天手打排班。常见规则是周一到周五白班、周末夜班人员按用户表顺序轮转。下面这个存储过程生成指定年月的排班计划参数只有两个年份和月份。CREATE PROCEDURE sp_GenerateDutyPlan Year INT, Month INT AS BEGIN SET NOCOUNT ON; SET XACT_ABORT ON; BEGIN TRAN; DECLARE StartDate DATE DATEFROMPARTS(Year, Month, 1); DECLARE EndDate DATE EOMONTH(StartDate); -- 重新生成前先清掉当月旧计划避免重复数据 DELETE FROM DutyPlan WHERE DutyDate BETWEEN StartDate AND EndDate; ;WITH Numbers AS ( SELECT 0 AS n UNION ALL SELECT n 1 FROM Numbers WHERE n 31 ), DaysOfMonth AS ( SELECT DATEADD(DAY, n, StartDate) AS DutyDate FROM Numbers WHERE DATEADD(DAY, n, StartDate) EndDate ) INSERT INTO DutyPlan (UserId, DutyDate, ShiftId, Status) SELECT u.UserId, d.DutyDate, CASE WHEN DATEPART(WEEKDAY, d.DutyDate) IN (1, 7) THEN 2 ELSE 1 END AS ShiftId, 0 AS Status FROM DaysOfMonth d CROSS JOIN ( SELECT TOP 10 UserId FROM DutyUser WHERE IsEnabled 1 ORDER BY UserId ) u; COMMIT; END参数说明Year、Month决定生成哪个月DATEFROMPARTS拼出月初日期EOMONTH算出月末Numbers递归CTE生成1号到月底的所有日期最大31天够用CROSS JOIN把每个日期和值班用户做笛卡尔积再用DATEPART(WEEKDAY)判断周末。这里有个坑DATEPART(WEEKDAY)的结果受SET DATEFIRST影响默认周日是1周一是2如果你改了DATEFIRST判断逻辑要跟着调。注意这个写法适合人数不超过10人的小团队人数多了会出现同一天排给多人的情况实际项目里一般会在规则层再加一个人数过滤或者轮转序号。CROSS JOIN的轮转顺序是按UserId排的要改成按上次值班日期轮转得在存储过程里加一个排序号字段这个可以放到后期功能里再补。3.2 换班申请与审批状态机 唯一性校验换班是值班系统里最容易产生数据冲突的地方。A和B换班如果两边都同时操作就可能出现一条排班记录被换走两次的情况。这个资源把审批逻辑放在存储过程里事务内做校验能有效避免并发窗口。protected void grdPlan_RowCommand(object sender, GridViewCommandEventArgs e) { if (e.CommandName ApplySwap) { int sourcePlanId Convert.ToInt32(e.CommandArgument); // 把来源排班ID放到ViewState审批页提交时再取 ViewState[SourcePlanId] sourcePlanId; Response.Redirect(SwapApply.aspx?planId sourcePlanId); } }换班申请页填好对方排班ID和理由之后提交时调用审批存储过程。审批时最关键的是下面这段状态校验CREATE PROCEDURE sp_AuditSwap SwapId INT, Status TINYINT AS BEGIN SET NOCOUNT ON; DECLARE PlanA INT, PlanB INT; -- 取出换班申请两边的排班ID SELECT PlanA PlanIdA, PlanB PlanIdB FROM DutySwap WHERE SwapId SwapId; IF Status 1 BEGIN -- 校验两条排班都是正常状态任何一条已换过就不能再换 IF EXISTS ( SELECT 1 FROM DutyPlan WHERE PlanId IN (PlanA, PlanB) AND Status 0 ) BEGIN RAISERROR(其中一条排班已经参与过换班不能重复操作, 16, 1); RETURN; END -- 两边的状态同时改成已换班 UPDATE DutyPlan SET Status 1 WHERE PlanId PlanA; UPDATE DutyPlan SET Status 1 WHERE PlanId PlanB; UPDATE DutySwap SET Status 1 WHERE SwapId SwapId; END ELSE BEGIN -- 拒绝只更新申请状态排班计划保持原样 UPDATE DutySwap SET Status 2 WHERE SwapId SwapId; END END逻辑说明存储过程先把待审申请的两个排班ID取出来通过判断DutyPlan.Status是否等于0来保证排班记录没被换过两条排班同时更新状态要么都成功要么都失败事务保证一致性。应用层校验最大的问题是两条SQL语句之间存在时间差理论上会出现两边同时读到Status0然后都执行更新存储过程把查询和更新放在同一个事务批次里风险小得多。3.3 值班记录与统计报表聚合查询与导出兜底值班记录页就是值班人登录后按排班日期写交接内容一张表单提交后写入DutyLog。统计报表则用聚合SQL一个月跑一次直接给管理员的页面出数据。下面是最常用的每人值班数统计统计某个月的每人总值班次数、夜班次数和换班次数。SELECT u.UserName, COUNT(*) AS TotalDuty, SUM(CASE WHEN s.ShiftName N夜班 THEN 1 ELSE 0 END) AS NightDuty, SUM(CASE WHEN p.Status 1 THEN 1 ELSE 0 END) AS SwapCount FROM DutyPlan p JOIN DutyUser u ON u.UserId p.UserId JOIN DutyShift s ON s.ShiftId p.ShiftId WHERE p.DutyDate BETWEEN StartDate AND EndDate GROUP BY u.UserName ORDER BY TotalDuty DESC;参数说明StartDate和EndDate是统计区间的起止日期传当月第一天和最后一天。SUM(CASE WHEN ...)是聚合里常用的条件计数写法比COUNT加WHERE再拼接多个结果集方便得多。排序用TotalDuty DESC可以让值班次数多的人排前面方便管理员一眼看出工作量不平衡。报表页面我一般会再加一个月份选择器选中后往这个SQL传两个日期参数整个报表页不需要接第三方图表库直接用GridView渲染出来就行。4. 部署与配置IIS、连接串与目录权限三件套4.1 Web.config连接串与发布方式老项目的连接串经常是明文写在Web.config里的而且要改IP、账号、密码还要改配置文件里的整段字符串。建议把这个资源包里的连接串单独抽到connectionStrings节点里发布时只改这一处不用在代码里到处找SQL连接。connectionStrings add nameDutyConn connectionStringData Source127.0.0.1;Initial CatalogDutyDB;User IDduty_user;Passwordxxxx;MultipleActiveResultSetsTrue; providerNameSystem.Data.SqlClient / /connectionStrings参数说明Data Source是数据库实例地址Initial Catalog是数据库名MultipleActiveResultSetsTrue允许在同一个连接上同时执行多个查询排班页面里同时读取列表和统计时能减少连接占用。如果服务器是Windows认证方式连接串可以改成Integrated SecurityTrue。要注意的是密码里如果包含分号、引号这类特殊字符必须用XML实体转义不然配置文件直接解析失败。发布方式上老项目常用“发布网站”直接拷到服务器aspx文件保留源码改动页面比较方便预编译发布会把所有C#代码编译成DLL服务器上看不到后台代码。两种方式对值班系统来说都够用但如果接的是外包活我一般选预编译防止源码泄露。发布方式服务器上是否保留aspx源码适合场景发布网站保留页面可改内部运维、频繁微调预编译只留编译后的DLL交付外包、代码保护4.2 IIS应用池与身份部署到IIS时新手最容易翻车的点是应用池没配对页面一打开就报503或者无法识别的错误。值班系统的页面是基于WebForms的应用池的.NET CLR版本要选v4.0托管管道模式建议用集成模式。经典模式下有些控件事件和控制器的处理方式不同跑起来会出现诡异的页面行为排查半天才发现是管道模式不对。配置项建议值说明.NET CLR版本v4.0对应.NET Framework 4.x托管管道模式集成模式与模块、授权协同更顺应用程序池标识ApplicationPoolIdentity默认即可权限隔离创建完应用池后网站绑定里把主机头设置成内网机器名或IP端口可以用80也可以单独指定一个像8080这样的端口。如果服务器上已经跑了别的站点端口别冲突否则站点一直处于停止状态日志里不报错很难定位。4.3 文件目录权限与上传目录值班系统如果做了交接班图片上传IIS进程就需要对上传目录有写权限。默认的ApplicationPoolIdentity权限很有限直接往站点目录里写文件会报“对路径的访问被拒绝”。解决办法是在服务器上把上传目录的写权限显式授给当前应用池的虚拟账号命令可以这样敲icacls D:\DutySite\Uploads /grant IIS APPPOOL\DutyPool:(CI)(OI)M参数说明D:\DutySite\Uploads是上传目录的物理路径DutyPool是应用池名称(CI)(OI)表示容器和对象都继承这个权限M是修改权限比完全控制少一点够用。跑完命令后最好手动在浏览器里传一张图试试能传上去说明权限通了。日志目录也是一样Global.asax里写文件日志的路径需要IIS用户有写权限否则异常记录写不进去后面排错就没有依据。5. 值班系统常见的坑与排查五条翻车记录5.1 线上报错但日志文件一片空白现象用户点“生成排班”后页面直接报黄页错误管理员打开服务器上的日志文件却发现一个字都没有。原因很多老项目只在页面里捕获了异常没有在应用层面统一记录异常一旦发生在存储过程调用或事件绑定里就直接抛到页面层日志系统没接到。解决在Global.asax里加Application_Error事件把还活着的异常抓下来写入日志文件。protected void Application_Error(object sender, EventArgs e) { Exception ex Server.GetLastError(); string logPath Server.MapPath(~/Logs/error_ DateTime.Now.ToString(yyyyMMdd) .log); System.IO.File.AppendAllText(logPath, DateTime.Now.ToString(yyyy-MM-dd HH:mm:ss) ex.ToString() Environment.NewLine); Server.ClearError(); }逻辑说明App_Data或Logs目录需要IIS写权限这段代码里文件路径按天拆开方便按日期翻问题。抓到异常后调用Server.ClearError()是为了防止它继续往后抛造成二次报错。从那之后我每接一个老项目第一件事就是确认全局异常日志能不能写进去不然排查问题等于摸黑。5.2 排班页面刷新后数据丢失现象管理员在排班页调好了几行数据一按F5刚填的内容全没了提示重新登录。原因Session默认是InProc模式存在IIS进程内应用池一旦回收所有登录状态和页面暂存数据全部消失。解决让Session不依赖应用池进程改用StateServer或SQL Server存Session如果不想改架构至少在排班这种关键页面把暂存数据写进数据库不能在Session里留关键业务数据。常见的状态配置是在Web.config的system.web节点里加sessionState模式整套值班系统如果只是内部几十个人用StateServer就够了。5.3 连接池耗尽导致登录超时现象系统运行一两个月后某天早上所有人登录都报“Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool”。原因有人写数据访问代码时只Open不Close或者用了DataTable但没有释放DataAdapter关联的连接连接池的连接全部被占满。解决把所有SqlConnection改成using块包裹确保方法结束或异常时连接释放。// 反面只new不释放 SqlConnection conn new SqlConnection(connStr); conn.Open(); // 正面using块保证Dispose using (SqlConnection conn new SqlConnection(connStr)) { conn.Open(); using (SqlCommand cmd new SqlCommand(sql, conn)) { // 执行查询 } }参数说明连接池默认开启Max Pool Size默认是100这个数值不是越大越好池只是复用连接不是无限开连接。修完代码后重启应用池连接池会被清空之后再观察一两个月超时一般就再没出现过。5.4 部署后CSS和图片全部404现象本地开发一切正常发布到IIS后页面裸奔样式全丢图片也打不开。原因aspx页面里用了相对路径引用CSS比如css/style.css当页面处在子目录或虚拟目录下时相对路径变成了子目录下的cssIIS自然找不到。解决统一用根路径或ResolveUrl生成绝对路径模板页里的写法是这样link href% ResolveUrl(~/Content/site.css) % relstylesheet /逻辑说明~会解析到当前站点的根路径ResolveUrl拿到的是完整的应用程序根路径无论在哪个子目录都能正确指到Content/site.css。这个坑在本地调试时不容易出现因为本地路径和最终部署路径一致只有部署到虚拟目录或子目录时才暴露。5.5 日期又少了一天UTC与格式化现象值班记录页显示的日期是前一天或者Excel导出里日期变成了带时间的乱码。原因数据库里存的字段是DATETIME带时分秒页面绑定GridView时没有指定格式化字符串默认把2025-03-15 00:00:00整个输出另外如果服务器Region设为UTC而C#代码里用了ToLocalTime会出现差一天。解决排班日期字段在表里就用DATE类型页面显示统一用DataFormatString{0:yyyy-MM-dd}取数据时用Convert.ToDateTime转完再ToString格式化不要拿着DataRow里的值直接ToString。// 错误item[DutyDate]是object直接ToString输出完整时间 object rawDate row[DutyDate]; string bad rawDate.ToString(); // 正确先转DateTime再格式化 string good Convert.ToDateTime(rawDate).ToString(yyyy-MM-dd);逻辑说明Convert.ToDateTime会根据服务器区域设置解析如果服务器是UTC时区和数据库本地时间会有偏差。内部系统最稳妥的做法是不做时区转换数据库存什么就显示什么统一格式字符串所有列表、报表、导出Excel都用同一个格式日期类问题基本能根治。6. 进阶改造统一鉴权、字典缓存与报表导出6.1 统一鉴权所有页面继承一个BasePage老值班系统的登录校验经常散落在每个页面的Page_Load里代码重复且容易漏。一个有效做法是新增一个BasePage类让所有业务页面继承它在OnInit阶段判断登录状态。public class BasePage : System.Web.UI.Page { protected int CurrentUserId { get; private set; } protected override void OnInit(EventArgs e) { if (Session[UserId] null) { Response.Redirect(~/Login.aspx?returnUrl Server.UrlEncode(Request.RawUrl)); } CurrentUserId (int)Session[UserId]; base.OnInit(e); } }OnInit比Load早登录失效时能第一时间跳走带returnUrl参数可以让用户登录后回到原页面。6.2 字典缓存班次数据不每次查库班次表这种基本不变的字典数据每次打开排班页都查库属于白白消耗连接。我一般会在数据访问层套一个Cache缓存首次读取后缓存30分钟管理员调整班次后手动清缓存。private DataTable GetShifts() { if (Cache[DictShift] null) { // 从数据库加载班次表 Cache.Insert(DictShift, dt, null, DateTime.Now.AddMinutes(30), TimeSpan.Zero); } return (DataTable)Cache[DictShift]; }缓存过期时间设成30分钟一个周期数据变化后最多延迟半小时生效内部系统完全够用。6.3 报表导出不引入第三方库的Excel方案统计报表要导出Excel老服务器不一定连外网不方便装NuGet包。经验做法是直接输出HTML表格并声明Excel的ContentType中文导出不乱码的关键是编码设成GB2312。Response.Clear(); Response.ContentType application/vnd.ms-excel; Response.ContentEncoding Encoding.GetEncoding(GB2312); Response.AddHeader(Content-Disposition, attachment;filenameDutyReport.xls); Response.Write(tabletrtd值班人/tdtd值班次数/td/tr); Response.Write(/table); Response.End();这种方式生成的报表用Excel和WPS都能打开适合报表量不大、格式简单的场景。从那以后我每次维护这类型的老系统都强制走一遍先确认全局异常日志能写再检查Session过期策略最后盯一遍上传目录权限。旧系统不是不能动而是每一步都要给后来的人留好后悔药。希望帮到你。本文还有配套的精品资源点击获取
到O(n)的思维转换)
