dotnet 推荐 LightWorkFlowManager 轻量的工作过程管理库

幸运号

本文将和大家推荐我团队开源的 LightWorkFlowManager 轻量的工作过程管理库，适合任何需要执行工作过程的应用逻辑，可以方便将多个工作过程拼凑起来，且自动集成重试和失败处理，以及日志和上报功能
这个 LightWorkFlowManager 轻量的工作过程管理库是我所在的团队在 GitHub 上使用最友好的 MIT 协议开源的库，请看 https://github.com/dotnet-campus/LightWorkFlowManager
这个 LightWorkFlowManager 轻量的工作过程管理库现在已经在我团队的正式产品应用上运行有半年了，相对来说比较稳定。使用过程中如果有任何问题，都欢迎在 GitHub 上新建 Issues 进行反馈
世界上有许多现有的工作过程管理，那为什么还重新造了一个？没啥原因，自己造的用的顺手。这个 LightWorkFlowManager 库在功能上和其他的工作过程管理库相比要缺失许多，但胜在轻量。且 LightWorkFlowManager 最重要的卖点就是对调试友好，适合用在本身复杂度就比较好的逻辑情况下，可以有效降低引入工作过程管理模块本身带来的额外复杂度
许多现有的功能齐全的工作过程管理库都是在 ASP.NET Core 上使用的。然而我这里的需求是在客户端应用框架上使用，且大部分情况下是在用户的设备上运行的，许多服务依赖本身是不存在的。尽管许多现有的功能齐全的工作过程管理库都可以通过配置的形式将其切换到单机内运行，然而这样做将在大部分时候不是库的推荐用法，用起来没有那么顺。为此我所在的团队开发了 LightWorkFlowManager 轻量的工作过程管理库，这个库可以很方便在客户端框架上运行，比如在 WPF 应用程序、在 MAUI 应用程序上运行。同时 LightWorkFlowManager 也兼顾 ASP.NET Core 服务本身，特别是依赖注入部分，可以和默认的服务的依赖注入相连接
以下是 LightWorkFlowManager 轻量的工作过程管理库的使用方法
按照 dotnet 的惯例，先安装 NuGet 库，请看 https://www.nuget.org/packages/dotnetCampus.LightWorkFlowManager
在开始介绍使用方法之前，需要先介绍一下 LightWorkFlowManager 里面的概念。在 LightWorkFlowManager 里面定义了 MessageWorkerManager 类型，将其作为工作器的管理器，用途就是将各个工作器串联起来，且运行起来，这个 MessageWorkerManager 就是 LightWorkFlowManager 的入口类型
在 LightWorkFlowManager 里面定义了工作器的基础类型就是 MessageWorker 类型，所有的业务上的开发者自定义的工作器都需要直接或间接继承 MessageWorker 类型
了解基础概念之后，接下来就开始编写一个简单的逻辑作为例子
使用方法

1、 创建 MessageWorkerManager 对象。创建 MessageWorkerManager 工作器管理器即可作为承载工作器的框架，请为每次单独的任务创建独立的 MessageWorkerManager 对象

1.             // 每个任务一个 TaskId 号
2.             string taskId = Guid.NewGuid().ToString();
3.             // 相同类型的任务采用相同的名字，比如这是做 PPT 解析的任务
4.             string taskName = "PPT 解析";
5.             // 提供容器
6.             IServiceScope serviceScope = serviceProvider.CreateScope();
8.             var workerManager = new MessageWorkerManager(taskId, taskName, serviceScope);

复制代码

2、 定义 Worker 工作器。以下例子代码定义了模拟业务代码的 FooWorker 工作器，可以在 FooWorker 重写的 DoInnerAsync 方法里面编写执行的业务代码。以下代码的 InputType 和 OutputType 分别是工作器的输入和输出类型，每个工作器的输出对象都会自动加入到 MessageWorkerManager 的过程上下文缓存里面

1. record InputType();
3. record OutputType();
5. class FooWorker : MessageWorker<InputType, OutputType>
6. {
7.     protected override ValueTask<WorkerResult<OutputType>> DoInnerAsync(InputType input)
8.     {
9.         ...
10.     }
11. }

复制代码

3、 执行 Worker 工作器。 完成类型的定义之后，接下来演示如何通过 MessageWorkerManager 将 FooWorker 运行起来

1.             var result = await workerManager
2.                 .GetWorker<FooWorker>()
3.                 .RunAsync();

复制代码

以上代码也可以简写为以下代码

1.             var result = await workerManager.RunWorker<FooWorker>();

复制代码

以上代码运行的前提是先注入 FooWorker 所需的 InputType 类型的对象。下文将告诉注入工作器参数部分的更多细节
机制和功能

工作器参数

工作器参数通过 MessageWorkerManager 工作器管理的 IWorkerContext 上下文读取。每个工作器的可返回值类型都会自动被设置到 IWorkerContext 上下文里面。如此即可自动实现上一个 Worker 的输出作为下一个 Worker 的输入
在每个工作器里面，都可以通过 SetContext 设置上下文信息
在开始执行工作器时，还可以手动设置输入参数，如以下例子

1. // 例子1：先获取工作器，再赋值给到工作器的执行方法
3.             await Manager
4.                 .GetWorker<FooWorker>()
5.                 .RunAsync(new InputType());
7. // 例子2： 通过 SetContext 进行设置参数，再执行工作器
8.             await Manager
9.                 .SetContext(new InputType())
10.                 .RunWorker<FooWorker>();

复制代码

如果有些工作器之间的输入和输出参数需要进行转换，也可以 SetContext 传入转换委托进行参数转换

1. // 以下例子将当前上下文里的 Foo1Type 类型转换为 FooWorker 需要的 Foo2Type 参数
2.            await Manager
3.                 .SetContext((Foo1Type foo1) => ConvertFoo1ToFoo2(foo1))
4.                 .RunWorker<FooWorker>();

复制代码

异常中断和重试

每个 Worker 都可以返回 WorkerResult 类型的返回值，可以在返回值里面告知框架层是否当前的 Worker 执行成功。在执行失败时，可以赋值错误码，方便定位调试或输出。在执行失败时，可以返回告知框架层是否需要重试
中断后续的工作器执行有两个方法：
方法1： 通过返回状态为失败的 WorkerResult 返回值。一旦工作管理器的状态为 IsFail 状态，将会阻止所有的没有标记 CanRunWhenFail 为 true 的工作器的执行。换句话说就是除了哪些不断成功或失败状态都要执行的 Worker 工作器之外，其他的工作器都将不会执行，包括 SetContext 里面的委托转换也不会执行
方法2： 通过抛出异常的方式，通过 dotnet 里面的异常可以让后续逻辑炸掉不再执行
以上两个方法都是框架推荐使用的。框架设计的偏好是如果在重视性能的情况下，尽量使用方法1的方式中断执行。如果是在复杂的业务逻辑，有大量业务逻辑穿插在工作过程之外，则可以方便通过方法2进行中断
在 Worker 里执行其他 Worker 工作器

在一个 Worker 里面，可以执行其他的 Worker 工作器，如此可以比较自由的实现分支逻辑，套娃决定执行工作器
例子如下：
假定有一个 Worker2 工作器，定义如下：

1.     class Worker2 : MessageWorker<InputType, OutputType>
2.     {
3.         protected override ValueTask<WorkerResult<OutputType>> DoInnerAsync(InputType input)
4.         {
5.             return SuccessTask(new OutputType());
6.         }
7.     }
9.     record InputType();
11.     record OutputType();

复制代码

有另一个 Worker1 工作器，可以在 Worker1 里面执行 Worker2 工作器：

1.     class Worker1 : MessageWorkerBase
2.     {
3.         public override async ValueTask<WorkerResult> Do(IWorkerContext context)
4.         {
5.             await Manager
6.                 .GetWorker<Worker2>()
7.                 .RunAsync(new InputType());
9.             return WorkerResult.Success();
10.         }
11.     }

复制代码

委托工作器

有一些非常小且轻的逻辑，也想加入到工作过程里面，但不想为此定义一个单独的工作器。可以试试委托工作器，如以下代码例子

1.             var delegateMessageWorker = new DelegateMessageWorker(_ =>
2.             {
3.                 // 在这里编写委托工作器的业务内容
4.             });
6.             var result = await messageWorkerManager.RunWorker(delegateMessageWorker);

复制代码

如果连 DelegateMessageWorker 都不想创建，那也可以直接使用 MessageWorkerManager 的 RunWorker 方法传入委托，如以下代码例子

1.             await messageWorkerManager.RunWorker((IWorkerContext context) =>
2.             {
3.                 // 在这里编写委托工作器的业务内容
4.             });

复制代码

来源:https://www.cnblogs.com/lindexi/archive/2023/10/09/17750753.html
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！