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

发布于 2024-07-12 02:38:57 字数 1272 浏览 3 评论 0原文

我正在设计一个系统，该系统允许我将广泛的任务表示为工作流，并通过 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 派生的对象，它具有子类实现的抽象 Execute() 方法，封装了这些操作的行为。 Execute() 方法在工作流框架中被调用 - 我有一个 WorkflowRunner 类，它枚举 Workflow()、围绕工作项包装前置事件和后置事件，并在事件之间调用 Execute。这允许使用应用程序在工作项之前或之后执行所需的任何操作，包括取消、更改工作项属性等。

我认为，这一切的好处是我可以用工作项来表达任务的核心逻辑负责完成工作，我可以用一种相当简单、几乎程序化的方式来做。另外，因为我使用 IEnumerable 以及支持它的 C# 语法糖，所以我可以编写这些工作流程 - 就像使用和操作子工作流程的更高级别工作流程。例如，我编写了一个简单的工作流程，仅将两个子工作流程交错在一起。

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

原文

I'm in the process of designing a system that will allow me to represent broad-scope tasks as workflows, which expose their workitems via an IEnumerable method. The intention here is to use C#'s 'yield' mechanism to allow me to write psuedo-procedural code that the workflow execution system can execute as it sees fit.

For example, say I have a workflow that includes running a query on the database and sending an email alert if the query returns a certain result. This might be the workflow:

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 and EmailWarehouse are objects deriving from WorkItem, which has an abstract Execute() method that the subclasses implement, encapsulating the behavior for those actions. The Execute() method gets called in the workflow framework - I have a WorkflowRunner class which enumerates the Workflow(), wraps pre- and post- events around the workitem, and calls Execute in between the events. This allows the consuming application to do whatever it needs in before or after workitems, including canceling, changing workitem properties, etc.

The benefit to all this, I think, is that I can express the core logic of a task in terms of the workitems responsible for getting the work done, and I can do it in a fairly straightforward, almost procedural way. Also because I'm using IEnumerable, and C#'s syntactic sugar that supports it, I can compose these workflows - like higher-level workflows that consume and manipulate sub-workflows. For example I wrote a simple workflow that just interleaves two child workflows together.

My question is this - does this sort of architecture seem reasonable, especially from a maintainability perspective? It seems to achieve several goals for me - self-documenting code (the workflow reads procedurally, so I know what will be executed in what steps), separation of concerns (finding low inventory items does not depend on sending email to the warehouse), etc. Also - are there any potential problems with this sort of architecture that I'm not seeing? Finally, has this been tried before - am I just re-discovering this?

分享到QQ

分享到微博