抹茶柚子冰1. 为什么现在还用WinForm做企业人事系统：技术选型背后的现实逻辑
这两年别人听到我还在用WinForm接项目，第一反应通常是"都什么年代了，这玩意还有人用？"但我个人实测下来，在传统企业、制造业工厂、政务类周边项目这些真实场景里，WinForm不仅能用，而且往往是比Web方案更省心的选择。很多企业内部压根没有专职前端，也没有K8s集群，甚至连一台像样的Linux服务器都没有，你给他一套需要Node构建、Nginx反向代理、Redis缓存的前后端分离系统，他根本维护不动。
WinForm这套方案真正解决的是"装上去就能用、出问题有人能修"的问题。一个典型的场景是这样的：客户人事部有三四个人，IT就一位老哥，服务器是Windows Server 2008 R2，数据库装的是SQL Server 2008。你交付一套B/S架构系统，他得配IIS、配应用程序池、配防火墙端口，稍微有点风吹草动就抓瞎。而WinForm程序只要在他电脑上装个客户端，连接字符串指向服务器数据库，双击图标就能打开。出了Bug，远程桌面上去改一改、重新发布一个exe，十分钟搞定。
我承认WPF在UI表现力上确实强不少，工控领域也一直有"WPF为何替代不了WinForm"的讨论，但对于人事管理这类以表单、表格、增删改查为核心的系统来说，WinForm的成熟度、稳定性和生态积累是经过十几年验证的。你不需要炫酷的动画，不需要复杂的MVVM数据绑定，你需要的是DataGridView能稳稳显示几千行数据、导出Excel不丢格式、部署到低配电脑不卡顿。
这套系统的目标定位非常明确：给中小型企业一个不需要高成本定制、不用养一支开发团队也能用得起来的内部工具。它没有用任何重量级框架，没有引入微服务，没有上前端工程化，甚至没有用ORM框架，就是纯C# + ADO.NET + SQL Server（也可以换SQLite）。听起来很"原始"，但这种原始恰恰是它的优势——你随便找一个能看懂C#的开发，半天就能上手维护；你把源码丢给客户公司的IT，他啃两个月也能自己改需求。
接下来，我会把整套系统的模块边界、数据库设计、数据访问层封装、业务流程和核心代码，以及我在交付过程中踩过的典型问题，全部拆开来讲清楚。你可以把它当成一套可以实际改用的基座，也可以把它当成一份WinForm中型项目的解剖样本。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 业务模块划分：六大功能域，一话讲清边界
人事管理系统听起来简单，真正做需求调研的时候你才会发现里面全是细节。员工档案管什么、考勤数据从哪来、薪资怎么算、合同什么时候到期、组织架构谁来维护、账号权限控制到什么粒度，每一块都能展开聊很久。如果一开始不把模块边界划清楚，开发过程中必然会出现"这个功能该放哪个窗体"的纠结，最后代码越写越乱。
这套系统我最终划分成了六大模块，基本覆盖了中小型企业的全部人事管理需求：
- 员工档案管理：员工入职、转正、调动、离职全生命周期信息维护。
- 考勤管理：打卡流水导入、请假加班登记、日汇总与月度报表。
- 薪资管理：薪资结构配置、月度计算、工资条生成、历史查询。
- 合同管理：劳动合同签订记录、续签提醒、到期预警。
- 组织架构管理：部门维护、岗位维护、部门员工分布。
- 系统管理：用户账号、角色权限、操作日志。
模块划分的核心原则是"一个模块只回答一类业务问题"。比如"员工离职"这件事，会涉及员工档案状态变化、考勤截止、薪资结算、合同终止四个模块，但你不能为此单独造一个"离职管理"模块，因为离职本质上是员工状态的一种变化，它应该由员工档案模块来驱动，其他模块通过接口或事件联动配合。
在数据关系上，员工表是全局的主表，用EmployeeId作为唯一标识。考勤、薪资、合同都以EmployeeId作为外键关联。部门和岗位独立维护，员工表内只保存DepartmentId和PositionId，而不是直接存部门名称。这样设计带来一个最直接的收益：改一个部门名称，只需要update一条记录，所有关联员工自动生效。你要是把部门名字直接冗余在员工表里，后面改起名来就是一场灾难。
我记得给一家做机械加工的企业做需求调研时，他们人事部主管给我提了一堆"想要的功能"，包括试工期提醒、转正自动发邮件、员工生日祝福、培训记录等。这些需求看着都合理，但优先级和模块归属完全不一样。后来我在需求文档里把所有功能重新归类，标清哪些是基础模块、哪些是增强功能、哪些可以二期再做，客户看了瞬间就明白了自己的真实需求是什么。模块化不只是代码层面的概念，需求调研阶段一样需要边界思维。
3. 数据库设计：员工表、考勤表、薪资表的关键细节
数据库设计是整个系统最不能省功力的部分。我见过很多半路出家的开发者，建表时想到什么加什么，字段命名随心所欲，主外键关系一塌糊涂。人事系统这种项目，做的是数据管理，数据结构一旦错了，后面所有代码都是在错误的基础上打补丁。这一章我挑三张核心表展开讲，剩下的表设计思路是完全一样的。
3.1 员工档案表：状态字段的设计不能拍脑袋
员工档案表是系统的绝对核心，字段设计直接影响后续所有模块的查询和统计逻辑。基础字段包括工号、姓名、性别、出生日期、身份证号、手机号、邮箱、入职日期、转正日期、部门、岗位、状态等。
员工状态字段是很多人容易设计错的地方。有人图省事，用一个bit类型存储"在职/离职"两种状态，结果真上线后各种不够用：试用期员工算不算在职？停薪留职的人还要不要做考勤？退休返聘人员的合同怎么处理？我在这套系统里用的是TINYINT类型，存状态码，1表示试用期，2表示正式在职，3表示离职，4表示停薪留职。用枚举在C#代码里做映射，界面上用下拉框约束输入。
员工表的建表语句如下，重点看几个关键约束：
sql复制CREATE TABLE [dbo].[Employee](
[EmployeeId] INT IDENTITY(1,1) PRIMARY