c# - 这是工作流式系统的良好设计吗？

Question

我正在设计一个系统，该系统允许我将范围广泛的任务表示为工作流，这些工作流通过 IEnumerable 方法公开其工作项。此处的目的是使用 C# 的“yield”机制允许我编写工作流执行系统可以在其认为合适的情况下执行的伪过程代码。

例如，假设我有一个工作流，其中包括在数据库上运行查询并在查询返回特定结果时发送电子邮件提醒。这可能是工作流程:

public override IEnumerable<WorkItem> Workflow() {
    // These would probably be injected from elsewhere
    var db = new DB();
    var emailServer = new EmailServer();

    // other workitems here

    var ci = new FindLowInventoryItems(db);
    yield return ci;

    if (ci.LowInventoryItems.Any()) {
        var email = new SendEmailToWarehouse("Inventory is low.", ci.LowInventoryItems);
        yield return email;
    }

    // other workitems here
}

CheckInventory 和 EmailWarehouse 是从 WorkItem 派生的对象，WorkItem 具有子类实现的抽象 Execute() 方法，封装了这些操作的行为。 Execute() 方法在工作流框架中被调用——我有一个 WorkflowRunner 类，它枚举 Workflow()，在工作项周围包装前后事件，并在事件之间调用 Execute。这允许消费应用程序在工作项之前或之后执行任何需要的操作，包括取消、更改工作项属性等。

我认为，所有这一切的好处是，我可以根据负责完成工作的工作项来表达任务的核心逻辑，而且我可以以一种相当直接、几乎是程序化的方式来完成。还因为我使用 IEnumerable 和支持它的 C# 语法糖，我可以组合这些工作流——就像使用和操作子工作流的更高级别的工作流。例如，我编写了一个简单的工作流程，它只是将两个子工作流程交织在一起。

我的问题是 - 这种架构看起来是否合理，尤其是从可维护性的角度来看？它似乎为我实现了几个目标—— self 记录代码(工作流按程序读取，所以我知道什么将在什么步骤中执行)、关注点分离(查找低库存项目不依赖于向仓库发送电子邮件)、等 - 另外 - 这种架构是否存在我没​​有看到的潜在问题？最后，这之前有没有尝试过 - 我只是重新发现了这个吗？

Answer 1

就我个人而言，这对我来说是一个“先买后建”的决定。我会先买东西再写。

我在一家相当大的公司工作，可能会花钱很愚蠢，所以如果你是为自己写这篇文章并且买不起东西，我会收回评论。

这里有一些随机的想法:

我会将工作流外化到一个配置中，我可以在启动时读取它，可能来自文件或数据库。

它看起来有点像带有状态、转换、事件和 Action 的有限状态机。

我希望能够插入不同的操作，以便即时自定义不同的流程。

我希望能够注册不同的订阅者，他们希望在特定事件发生时收到通知。

我不希望看到任何像电子邮件服务器那样硬编码的东西。我宁愿将其封装到一个 EmailNotifier 中，我可以将其插入到需要它的事件中。蜂鸣器通知怎么样？还是手机？黑莓？相同的架构，不同的通知程序。

你想包含一个用于人机交互的处理程序吗？我处理的所有工作流都是人工处理和自动处理的混合体。

您是否期望连接到其他系统，如数据库、其他应用程序、网络服务？

这是一个棘手的问题。祝你好运。