简介基于ASP.NET MVC5开发的工作流引擎完整源码面向需要搭建OA办公、CRM客户关系或HR人事系统的开发者也可作为学习主流MVC架构与前端框架的实战案例。项目内置可视化流程设计器和表单设计器可直观配置审批节点、流转条件与自定义表单帮助理解工作流引擎的核心设计思路。压缩包共2000个文件涵盖cs后端逻辑、cshtml视图页面、dll程序集、js脚本、css样式、sql数据库文件等类型配合Bootstrap和jQuery实现响应式界面整体大小约60.93MB目录结构清晰便于按模块研读。目前已有1094人学习下载源码中包含完整的项目文件、数据库脚本及辅助配置读者可以在此基础上二次开发快速搭建自己的流程管理模块同时深入掌握MVC5路由、控制器、视图、模型绑定等关键知识点。 工作流这个词在传统企业级系统里被喊了很多年但真正落地起来坑远比想象中多。前段时间我正好把一个基于 ASP.NET 的 MVC 工作流管理系统源码从头到尾梳理了一遍包括流程定义、表单绑定、节点路由、任务分发还把里面容易踩坑的几个位置做了重构。今天这篇就从这套系统的整体设计讲起把 MVC 架构下工作流引擎的实现思路、核心数据模型、动态表单、并发审批这些关键点一个个拆开。如果你正准备在 .NET 项目里引入轻量级工作流或者手里有一套类似的 asp.net 工作流源码但不知道怎么二次开发这篇应该能给你省不少时间。先交代一下背景。这套系统不是一个像 Flowable、Camunda 那样的重型 BPM 引擎它定位在中小型企业的内部审批场景比如请假、报销、合同会签、采购申请这一类。采用 ASP.NET MVC 作为整体架构数据库用 SQL Server前端用 Razor 视图加 jQuery。整个工作流内核是自己写的没有依赖第三方工作流组件这一点很重要因为当你拿到一套工作流管理系统源码时能不能改得动取决于它的核心逻辑是不是足够清楚而不是它用了多少高级框架。1. 工作流管理系统的整体设计思路1.1 你不是在做一个引擎而是在做一套业务骨架很多人一开始接触工作流源码容易误判重点以为核心就是把流程图画出来、节点连起来。真正做过你就知道工作流管理系统最花精力的地方其实是两件事一是流程实例在运行过程中如何准确、可控地从一个节点走到下一个节点二是流程和业务表单之间怎么解耦又怎么联动。这两件事处理好了后面加再多的审批节点、条件分支都是往里堆配置的事处理不好哪怕只有一个顺序流转也会在并发、驳回、撤回这些场景里翻车。我拿到这套源码后第一件事就是看它的流程引擎核心类发现它把流程定义和流程实例分得很清楚。流程定义描述的是模板比如“报销单审批流程”有哪几个节点、每个节点由谁审批、满足什么条件走哪个分支流程实例则是某一次具体的报销单它的当前节点在哪、审批记录有几条、表单数据填了什么。定义和实例分离这是工作流系统最基本也是最重要的一条设计原则后面所有的功能都是在这个基础上长出来的。1.2 为什么还在用 ASP.NET MVC 这套技术栈现在一聊工作流大家张口就是 Flowable、Activiti、Spring Cloud甚至有人觉得 2025 年了还在折腾 ASP.NET MVC是不是有点过时。我的看法不太一样。技术的价值在于匹配场景。很多企业内部系统是十来年前就开始积累的底层就是 .NET Framework 加 SQL Server业务数据、组织架构、权限系统全在上面。这种情况下用工作流管理系统源码直接嵌入进来比引入一套独立的 Java 服务或者在现有系统旁边再加一套流程引擎要稳得多。ASP.NET MVC 这套架构本身没什么大毛病它把控制器、视图、模型分得很清楚对于工作流这种“后端逻辑重、前端页面标准”的系统来说非常合适。工作流的后端要处理状态流转、规则判断、任务分配这部分写在控制器和服务层里逻辑边界很清楚前端的审批页面、流程监控页面都是表格加按钮的标准交互用 Razor 视图加 Ajax 就能做得很顺手完全不需要上个 Vue 或者 React 去凑热闹。1.3 轻量级引擎和专业 BPM 产品的定位差异这里得把话说清楚。这套系统的定位是“业务系统里的审批组件”而不是要成为一个通用 BPM 平台。它没有复杂的流程版本迁移没有 BPMN 2.0 的完整支持也没有专门的可视化流程设计器终端。流程设计靠的是一个简单的画布页面画出节点框和箭头存成 JSON 格式的流程定义。这种轻量方案的取舍逻辑是这样的在真实业务里企业对工作流的需求往往集中在两点一是流程要能灵活调整二是审批记录要完整可追溯。至于要不要支持会签、或签、条件分支这些功能内核里有就行界面朴素一点完全能接受。相比于引入 Camunda 这种重型引擎带来的学习成本和部署复杂度一套自己掌控核心逻辑的轻量级源码在长期维护上的性价比反而更高。2. 核心功能模块拆解2.1 流程定义用 JSON 描述流程不碰 BPMN这套源码里流程定义的核心是一个 JSON 结构。它没有把流程画成 BPMN 的 XML而是用一种更适合自己业务理解的格式来存储包括节点列表、连线列表、节点属性、节点间的跳转关系。比如一个带条件分支的采购审批流程定义出来大概长这样{ processKey: purchase_approval, nodes: [ { id: start, type: start, name: 开始, next: apply }, { id: apply, type: task, name: 申请人填写, assignee: ${starter}, next: manager_review }, { id: manager_review, type: task, name: 部门经理审批, assignee: ${starter.manager}, next: cto_review }, { id: cto_review, type: task, name: 技术总监审批, assignee: ${starter.dept tech ? cto : manager}, next: end }, { id: end, type: end, name: 结束 } ] }这种设计的好处有两个。第一JSON 结构直接对应代码里的实体类解析的时候只需要序列化和反序列化不用维护额外的解析器第二业务人员如果要调整流程改的是配置而非代码系统里做一个流程设计页面本质上是可视化地编辑这个 JSON。流程定义的版本管理也比 BPMN 轻松很多每次修改存一个新版本记录就行。2.2 表单引擎动态渲染是工作流的灵魂表单和工作流的关系是所有做工作流系统的人绕不开的难题。简单场景下每个流程节点绑定一个固定的实体类这没问题但一旦流程多了每加一个流程就要加表、加页面、加模型系统会越来越臃肿。这套源码采用的是表单定义加数据存储分离的方案流程定义里绑定表单定义表单定义描述有哪些字段、字段类型、校验规则字段数据则存放在一个通用的业务数据表里。一个典型的表单定义片段是这样的{ fields: [ { key: amount, label: 报销金额, type: number, required: true }, { key: reason, label: 报销事由, type: textarea, maxLength: 200 }, { key: receiptType, label: 发票类型, type: select, options: [增值税专用, 增值税普通, 电子发票] } ] }页面渲染时后端根据表单定义动态生成 HTML 控件用户提交后前端把数据序列化成一个 JSON 字符串存入业务数据表。这么做最大的受益方是后端新增一个审批流程不需要写新的数据表只需要配置流程定义和表单定义就能跑起来维护成本直线下降。当然动态表单也意味着数据查询和统计会略麻烦所以这套源码里对需要频繁检索的字段做了辅助列算是一个折中的方案。2.3 任务中心待办、已办、我发起的任务中心是用户接触工作流的最前线。这套系统的任务中心分成三个页签待办、已办、我发起的。每次流程推进到某个节点时系统会往待办任务表插入一条任务记录任务记录的 AppUserId 指向具体的审批人。谁登录就能看到属于自己的待办点进入就是审批页面。这一块实现值得学习的地方在于它把“任务实例”和“流程实例”做了分离。一个流程实例可能经过 5 个节点每个节点对应一条甚至多条任务记录任务记录有自己的完成状态、接收时间、完成时间。这样设计的好处是想查“谁在哪个环节耽误了太久”就特别容易。我之前见过不少工作流系统把任务和流程混在一起结果想统计某个环节的平均耗时得从流程历史表里翻出来逐条解析费劲得很。3. 数据模型与核心表设计3.1 五张核心表足以支撑轻量级工作流这套源码的数据库模型并没有设计得很复杂核心就是五张表流程定义表、节点定义表、流程实例表、任务实例表、流程历史表。我用表格列一下它们的关系和职责表名核心字段职责说明Workflow_ProcessDefinitionId, ProcessKey, Name, JsonContent, Version存储流程模板及相关版本信息Workflow_NodeDefinitionId, ProcessId, NodeId, NodeName, NodeType, Config流程节点的定义及属性配置Workflow_ProcessInstanceId, ProcessId, BusinessKey, CurrentNodeId, Status, CreatorId某一次业务发起对应的完整流程实例Workflow_TaskId, InstanceId, NodeId, AssigneeId, Status, StartTime, EndTime每个待办/已办任务节点记录Workflow_HistoryId, InstanceId, NodeId, OperatorId, ActionType, Comment, OperateTime操作轨迹及审批日志这个表结构看起来简单但实际跑起来很够用。流程实例和任务实例分离使得同一时间只能有一条“当前任务”在流转而历史表记录每一次操作支撑完整的审计追溯。对于没有复杂子流程、没有并行网关的中小型业务来说这种设计远比引入一张 BPMN 字节码表来得实在。3.2 状态机的流转逻辑工作流的本质是一个状态机。一个流程实例状态无非是运行中、已结束、已撤销一个任务实例状态无非是待办、已完成、已驳回。这套源码把状态流转写在一个统一的 WorkflowEngine 服务里任何操作——提交、审批通过、驳回、撤回、撤销——都走这个服务避免状态被散落在各个控制器里乱改。核心方法大概长这样public WorkflowResult CompleteTask(int taskId, string operatorId, bool approved, string comment) { var task _taskRepository.GetById(taskId); var instance _instanceRepository.GetById(task.InstanceId); if (task.Status ! TaskStatus.Pending) return WorkflowResult.Fail(任务已处理不可重复操作); // 写入历史记录 _historyRepository.Add(new WorkflowHistory { InstanceId instance.Id, NodeId task.NodeId, OperatorId operatorId, ActionType approved ? ActionType.Approve : ActionType.Reject, Comment comment, OperateTime DateTime.Now }); // 更新当前任务状态 task.Status approved ? TaskStatus.Completed : TaskStatus.Rejected; _taskRepository.Update(task); if (!approved) { // 驳回则流程回到上一节点或直接终止 instance.CurrentNodeId GetPreviousNode(instance, task.NodeId); instance.Status ProcessStatus.Running; } else { // 通过则推进到下一节点 var nextNode GetNextNode(instance, task.NodeId); if (nextNode null || nextNode.NodeType end) { instance.Status ProcessStatus.Completed; } else { instance.CurrentNodeId nextNode.NodeId; CreateTask(instance, nextNode); } } _instanceRepository.Update(instance); return WorkflowResult.Success(); }所有的分支跳转、驳回逻辑、结束判断都集中在这里控制器的代码就可以写得非常薄。这个设计的核心思想是“把变化收敛到一处”。流程审批的规则以后会越来越多今天加一个“金额大于 5000 必须总监审批”明天加一个“部门经理驳回后可以再提交”如果这些逻辑散落在各个按钮的点击事件里后期改起来就是灾难。4. 实操过程与关键代码实现4.1 动态表单的渲染与保存动态表单是工作流系统里最有技术含量的部分没有之一。它的难点不在渲染而在数据模型的设计。这套源码的做法是用一个 ProcessFormSchema 类来解析表单 JSON用 FormData 类来承载用户填写的 JSON 数据。public class DynamicFormService { public static string RenderForm(string formSchemaJson) { var schema JsonConvert.DeserializeObjectFormSchema(formSchemaJson); var html new StringBuilder(); foreach (var field in schema.Fields) { if (field.Type input) html.Append($input name{field.Key} classform-control /); else if (field.Type textarea) html.Append($textarea name{field.Key} classform-control rows3/textarea); else if (field.Type select) { html.Append($select name{field.Key} classform-control); foreach (var opt in field.Options) html.Append($option value{opt}{opt}/option); html.Append(/select); } } return html.ToString(); } public static Dictionarystring, object ParseFormData(FormCollection form, string formSchemaJson) { var schema JsonConvert.DeserializeObjectFormSchema(formSchemaJson); var data new Dictionarystring, object(); foreach (var field in schema.Fields) data[field.Key] form[field.Key]; return data; } }在视图中直接调用这个服务输出 HTML 字符串即可。用户提交后再解析回字典序列化之后保存。这套逻辑有一个值得注意的点校验不能只放在前端。动态表单的字段规则全部来自配置恶意用户完全可以通过接口直接提交没有校验的数据所以后端必须在 ParseFormData 之后遍历 schema逐字段做必填、长度、类型的校验这一点我在这套源码里看到它是做了的放在 FormValidator 的静态方法里也算一个值得借鉴的地方。4.2 审批节点的并发控制一个容易被忽略的大坑审批系统里最常见的并发问题长这样一个审批人同时打开两个浏览器页面对同一个任务点了两次“通过”或者流程到了会签节点多个审批人同时操作一条流程实例。如果不做并发控制任务状态会被覆盖历史记录会出现重复流程实例的当前节点可能会被错误地推进两次。这套源码处理方式是在数据库层面做的任务表加了一个 Version 字段或者直接用乐观锁更新任务状态的时候带上原始的 Version如果更新的影响行数为 0说明任务已经被别人处理过了直接返回“任务已处理”的提示。public WorkflowResult CompleteTask(Guid taskId, string operatorId, bool approved) { var task _taskRepository.FirstOrDefault(t t.Id taskId); if (task null || task.Status ! TaskStatus.Pending) return WorkflowResult.Fail(任务不存在或已被处理); task.Status approved ? TaskStatus.Completed : TaskStatus.Rejected; task.ApprovedBy operatorId; // 乐观锁Update 时附带原有 Version 值 var updateCount _taskRepository.UpdateWithVersion(task); if (updateCount 0) return WorkflowResult.Fail(请勿重复操作任务已被其他人处理); // ... 推进流程实例状态 }很多新手在写工作流系统时不会考虑这一步但生产环境里这种重复点击造成的“幽灵任务”会非常频繁。我建议所有做审批流的人在任务提交这个入口上必须做幂等处理乐观锁和请求去重至少要占一个。4.3 会签、或签、顺序会签的实现策略工作流系统中经常会遇到会签和或签的需求。所谓会签是多个审批人每个人都必须同意流程才往下走或签是只要有一个人同意就能通过。这套源码对这两种模式的处理方式是在节点配置里加一个 property比如{assigneeType: countersign}或者{assigneeType: orSign}然后在任务生成时为每个审批人都生成一条任务记录。区别体现在 CompleteTask 方法里会签节点需要判断当前实例在这个节点上的所有任务是不是都完成了如果还有人没处理流程实例就继续保持在这个节点或签节点则只要有一条任务被通过就把其他未处理的任务全部置为“已跳过”然后流程继续推进。这里为了保持流程的灵活性在判断所有任务完成状态的时候不是简单数一下任务表的记录数而是关联当前节点 ID 去统计因为同一个流程实例可能因驳回重新回到这个节点。4.4 撤回与驳回最容易把流程实例搞乱的操作撤回申请人发起后、审批人还没处理时申请人主动撤销和驳回审批人退回这两类操作在工作流源码里最容易出 bug。原因在于它们都涉及流程实例的当前节点回退而回退之后如果原节点已经生成了多条任务记录这些记录的状态要全部做置为取消。这套系统处理驳回的逻辑是分两种策略的一种是“驳回并结束”适用于填错单据这种场景流程直接终止申请人需要重新发起另一种是“驳回到指定节点”常见场景是审批人觉得申请材料有问题退回到申请人补充后再提交。驳回之后流程实例的 CurrentNodeId 变为目标节点同时该节点会自动生成一个新的待办任务给申请人。这里有一个细节如果是申请人重新提交不应该再走一遍发起流程而是直接让任务流转到之前驳回人的节点这需要在重新提交时判断当前节点和发起节点的关系。5. 常见问题与排查技巧实录5.1 流程实例卡在某个节点不动了这在工作流系统里是最常见的生产事故。排查思路大致如下先查流程实例表看 CurrentNodeId 指向哪里再查任务表看当前节点下有没有正在 Pending 的任务如果任务表里没有待办任务说明问题出在生成任务那一步如果任务表有待办再查任务分配给的 AssigneeId 是不是一个已经被禁用的用户或者这个用户根本没有权限访问待办中心。我在实际维护中踩过一个很典型的坑流程到达某个节点时CreateTask 方法里给审批人赋值用了approverId但某些历史流程创建时组织架构里的岗位已经调整审批人字段变成了空字符串。流程实例就卡在那里没有待办也没有报错数据库里静悄悄地就产生了僵尸任务。后来我在创建任务的地方加了一个非空校验为空时自动转到系统管理员节点这个问题才彻底解决。5.2 驳回之后表单数据被覆盖这类问题多出在动态表单保存逻辑没做场景区分。用户第一次提交的数据存入了 FormData 表被驳回后申请人修改了内容重新提交如果后端是简单地把整个表单 JSON 覆盖那么之前审批人看到的“第一次提交的数据”就没了。正确的做法是表单数据按“提交版本”存每次提交生成一条新记录关联流程实例 ID 和节点 ID查询历史时按版本倒序取就好。这套源码在 FormData 表里设计了一个 Version 字段重新提交时 Version 自增这种做法不但解决覆盖问题还能在审批历史里准确还原每一次提交的内容。5.3 动态表单字段多了之后页面越来越慢这个问题的根因在渲染时的重复解析。如果流程定义里的表单 JSON 有几 KB 或者十几 KB而且每次请求动态渲染表单页面时都重新反序列化、拼 HTML 字符串一旦并发上来性能就会肉眼可见地下降。这套系统最初也遇到了这个问题后来在表单渲染层加了一层内存缓存以表单定义 ID 为 Key缓存渲染好的 HTML 片段只有配置变更时才刷新缓存。实测下来页面打开耗时从 300ms 降到 50ms 左右效果非常明显。另外一个隐藏的坑是动态表单页面上传的文件怎么办这套源码里对附件统一走一个 UploadFile 表表单 JSON 里只存 fileId展示时再根据 fileId 回查附件地址。千万不要直接把文件的相对路径存进表单 JSON因为一旦文件跨服务器迁移所有历史数据的路径就全失效了。5.4 工作流和主业务系统的事务问题最后聊一个架构层面的心得。工作流引擎的操作和业务单据的操作理论上应该在同一个数据库事务里保证业务数据和工作流数据的一致性。比如用户发起一个报销单如果报销单插入成功但流程实例创建失败系统应该回滚不能让用户看到一条没有流程的单据。这套源码中发起流程的入口方法用了TransactionScope将业务数据和流程实例的插入包在同一个事务里。但要注意事务的粒度不能太大。流程推进时如果涉及发送邮件通知、调用外部接口这类操作绝对不能放在事务里否则外部系统没有及时响应数据库连接会一直被占用最终拖垮整个应用。经验做法是数据库操作放在事务里外部通知放在事务提交之后异步执行。6. 拿到源码之后我的二次开发建议如果你也想在自己的项目里跑一套 ASP.NET MVC 工作流系统我个人有几个不成文的建议。第一先跑起来再读代码。把源码部署到本地用两个账号模拟一条完整的审批流程发起、审批通过、驳回、重新提交走一遍之后你对流程定义、任务分配、状态流转会有直观的认识。带着这份认识再回头读 WorkflowEngine 的代码效率会高很多。第二优先改造权限体系。几乎所有开源的工作流源码权限模型都只覆盖了“谁是什么角色”但在真实企业里审批人常常要根据组织架构动态获取比如“发起人的直属上级”。这条规则大概率要在源码里改几个地方任务分配时要查出当前用户的上级、流程定义解析时要支持变量占位符、历史记录中要记录实际审批人是谁。调试谓权限逻辑最好的办法是先把最常用的几类流程梳理出来比如部门领导审批、跨部门会签、金额分级审批然后用特权账号模拟不同组织层级的人发起流程逐条验证。第三不要迷信可视化流程设计器。大部分开源工作流的流程设计器要么是嵌入式 JS 库调不通要么是画出来的 JSON 结构跟自己系统的解析逻辑不匹配。更务实的做法是先写好 JSON 流程定义配上流程图预览页用只读的方式展示给业务人员看让业务确认节点顺序。等后续确实有需求再在预览页上直接开发拖拽编辑能力优先级放在预览之后。我自己在项目里就是这样分工开发阶段用文本编辑器直接改 JSON业务确认阶段用预览页沟通落地阶段才上拖拽编辑器少踩了很多的坑。第四做好历史数据的清洗方案。很多旧系统里的工作流数据是脏乱的有任务状态错误、流程实例没有正确关联业务单据、审批记录缺失操作人。这些东西在接入新工作流系统之前最好是先在数据库里做一次盘点列清楚哪些流程是活跃的、哪些流程实例永远跑不完的、哪些历史数据需要迁移。如果直接导入脏数据会在新系统里继续毒化你的统计报表。最后再分享一个小技巧。工作流系统的调试强烈建议在开发环境里开启 SQL 日志把每一次状态更新的 SQL 语句打印出来。你会发现绝大多数“流程莫名其妙跳到了下一个节点”的问题都是因为更新语句少了 WHERE 条件、或者 WHERE 条件里没有带当前节点校验。这套源码里所有更新操作都严格要求带 InstanceId 和 NodeId 双条件这个习惯救了我很多次。做工作流系统最怕的就是把简单问题复杂化。轻量级引擎有轻量级引擎的做法只要核心状态机的逻辑清晰、动态表单的模型不别扭、并发控制做扎实这套源码就是一套能跑五年的业务基础设施。希望这篇拆解能帮你少走点弯路。本文还有配套的精品资源点击获取
