共计 1444 个字符,预计需要花费 4 分钟才能阅读完成。
背景与痛点
在 C# 开发中,复杂的业务逻辑往往涉及多个函数的协同调用。随着业务增长,开发者常遇到以下问题:

- 流程复杂度高:函数调用顺序和条件分支难以直观管理
- 状态维护困难:手动跟踪执行状态导致代码臃肿
- 错误处理繁琐:异常恢复机制需要重复编写
- 可扩展性差:业务流程变更时需要大量代码重构
技术选型对比
1. 原生状态机模式
- 优点:实现简单,无需额外依赖
- 缺点:状态转移逻辑硬编码,维护成本随状态数指数增长
2. 事件驱动架构
- 优点:松耦合,易于扩展
- 缺点:流程可视化困难,调试复杂度高
3. Workflow 方案
- 优势:
- 声明式定义业务流程
- 内置状态持久化和恢复机制
- 可视化设计器支持
- 微软官方维护(System.Activities)
核心实现细节
1. 关键组件
- Activity:工作流的基本执行单元
- WorkflowInstance:工作流运行时实例
- Bookmark:持久化恢复点
- WorkflowApplication:宿主程序交互接口
2. 典型工作流生命周期
- 定义 Activity 继承链
- 组合成 WorkflowDefinition
- 创建 WorkflowInstance
- 运行时通过 Bookmark 暂停 / 恢复
- 持久化到 SQL Server/AppFabric
代码示例
// 1. 定义自定义 Activity
public class SendEmailActivity : CodeActivity
{public InArgument<string> Recipient { get; set;}
protected override void Execute(CodeActivityContext context)
{var email = Recipient.Get(context);
// 实际发送逻辑
Console.WriteLine($"Sending to {email}");
}
}
// 2. 组合工作流
var workflow = new Sequence
{
Activities =
{new WriteLine { Text = "Starting workflow"},
new SendEmailActivity {Recipient = "user@domain.com"},
new Delay {Duration = TimeSpan.FromMinutes(5) },
new WriteLine {Text = "Workflow completed"}
}
};
// 3. 执行工作流
WorkflowInvoker.Invoke(workflow);
性能与安全性
优化建议
- 对长时间工作流启用
WorkflowServiceHost持久化 - 高并发场景使用
WorkflowApplication代替WorkflowInvoker - 配置适当的
ThrottlingBehavior参数
安全实践
- 对工作流定义进行 XSD 验证
- 限制自定义 Activity 的反射权限
- 加密持久化存储中的敏感数据
生产环境避坑指南
- 版本兼容:工作流定义变更后需处理已有实例的升级
- 超时设置:长时间运行工作流需配置合理的
TimeToPersist - 异常处理 :通过
TryCatch活动包裹关键节点 - 日志记录:实现自定义的
TrackingParticipant - 资源清理 :确保正确关闭
WorkflowApplication实例
进阶实践建议
尝试实现以下场景:
1. 创建带条件分支的订单审批工作流
2. 设计可中断 / 恢复的文件处理流程
3. 集成 WCF 服务作为工作流节点
遇到具体问题时,可以参考微软官方文档中的 StateMachine 示例,或通过 WorkflowDesigner.Rehosting 实现自定义设计器。
正文完
