工作流设计困境 - 状态机，是或否

发布于 2024-08-16 03:40:26 字数 611 浏览 9 评论 0原文

我是 WF 的初学者，但我读过一本书并进行了大量的谷歌搜索。我想编写一个库存管理服务。库存由具有状态的单个项目组成：

备用
、安装
、维修中的

项目可能会在每个状态花费数月时间，并且有数千个项目。

问题是，我是否为所有不同的状态创建状态机工作流程？或者我是否创建用于状态之间转换的工作流程？

如果我理解正确，如果我创建一个状态机工作流程，那么每个项目都将始终运行一个工作流程。这意味着数千个不断运行的工作流程。另外，我需要能够显示每个项目的状态快照，这意味着我必须以某种方式查询所有工作流程以了解它们当前所处的状态，或者在每次状态转换后保留到数据库。

然而，状态机工作流程在逻辑上听起来是正确的做法，因此我陷入了困境。

如果可以的话请帮助我:-)

谢谢！

更新：

假设我的状态多于上述 3 个状态，并且并非所有状态转换都是可能的。

赏金获得者：Maurice - 感谢其他人真正帮助我更多地了解工作流程、MS 工作流程基础和其他更轻量级的替代方案。不幸的是，只能有一个赏金获得者，莫里斯的回答及其评论对我帮助最大。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夏夜暖风 2024-08-23 03:40:26

状态机是一种非常强大的实现技术，尽管我建议您考虑一个名为由 Nicholas Blumhardt 开发的 StateLess 框架 (Autofaq Creator），因为它是状态机的极其简单的实现，避免了 Windows 工作流不必要的复杂性。他的方法避免了运行时引擎持有长时间运行的工作流的问题，因为状态是由简单的变量（例如字符串或整数）定义的。

这是一个示例状态机：

var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

phoneCall.Configure(State.OffHook)
    .Permit(Trigger.CallDialed, State.Ringing);

phoneCall.Configure(State.Ringing)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.CallConnected, State.Connected);

phoneCall.Configure(State.Connected)
    .OnEntry(() => StartCallTimer())
    .OnExit(() => StopCallTimer())
    .Permit(Trigger.LeftMessage, State.OffHook)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...

phoneCall.Fire(Trigger.CallDialled);
Assert.AreEqual(State.Ringing, phoneCall.State);

您的状态可以是一个整数，它允许您从数据库向其提供当前状态。这可以在状态机的构造函数上进行设置，如下所示：

var stateMachine = new StateMachine<State, Trigger>(
    () => myState.Value,
    s => myState.Value = s);

与运行 Windows 工作流所需的多个项目相比，您只需在一个程序集中即可实现这一点。维护成本极低，他们没有为您生成代码的“设计师”，等等。同样，它很简单，而且存在着美丽。

A state machine is a very powerful technique to implement, although I would recommend that you consider a framework called StateLess by Nicholas Blumhardt (Autofaq creator), as it is an amazingly simple implementation of a state machine that avoids the unnecessary complexity of Windows Workflow. His approach avoids the issue of long running workflows being held by a runtime engine, as the state is defined by a simple variable such as a string or int.

Here is a sample state machine:

var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

phoneCall.Configure(State.OffHook)
    .Permit(Trigger.CallDialed, State.Ringing);

phoneCall.Configure(State.Ringing)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.CallConnected, State.Connected);

phoneCall.Configure(State.Connected)
    .OnEntry(() => StartCallTimer())
    .OnExit(() => StopCallTimer())
    .Permit(Trigger.LeftMessage, State.OffHook)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...

phoneCall.Fire(Trigger.CallDialled);
Assert.AreEqual(State.Ringing, phoneCall.State);

Your state can be an integer which will allow you to feed it the current state from a database. This can be set on the constructor of the state machine as follows:

var stateMachine = new StateMachine<State, Trigger>(
    () => myState.Value,
    s => myState.Value = s);

You can implement this in just one assembly, compared to the multiple projects you need to run Windows Workflow. Maintenance is extremely low, their is no "designer" that generates code for your, etc. Again, it is simple, and there lies the beauty.

回复收藏 0 原文

坏尐絯 2024-08-23 03:40:26

不确定工作流程是否是您首先要寻找的。

工作流是发生的某种业务流程。这意味着该过程的开始和结束。您的描述听起来更像是您正在跟踪库存中保留的物品的库存。

当项目状态发生变化时，工作流程听起来更合适。例如，当一个项目安装完毕后发生故障并需要修复时，您将启动一个工作流程，用可用的零件替换该零件，将损坏的零件发送出去进行修复，最后将其作为修复好的零件返回仓库空闲的。工作流程将描述此过程，从报告损坏的物品开始，到修复或丢弃和更换物品结束。

最后一个工作流程很可能是一个状态工作流程，因为该项目会经历各个阶段，例如：

损坏并安装
损坏并更换
在商店进行维修
修复
等

回复收藏 0 原文

梦途 2024-08-23 03:40:26

鉴于您的添加（超过 3 个状态，并非允许所有转换），我将执行以下操作：

将每个项目的状态存储在项目本身中。
这可以非常轻松地实现：将成员添加到类或列到桌子等，正如其他人在他们的帖子/评论中已经提到的那样。
使用一个状态机（可以是从类的实例到具有合法转换的表的任何内容），该状态机保存您的业务逻辑，即状态之间允许的转换以及有关在项目发生时要执行哪些附加操作的知识改变它的状态。

然后，您需要做的就是使用状态机转换您的项目，每当发生外部事件时，就会强制/暗示这一点。

回复收藏 0 原文

送君千里 2024-08-23 03:40:26

好的。让我们看看我是否可以帮助你。让我们从设计开始：

设计一个状态机和一个工作流程是有意义的。两者只是对您的问题的不同看法，并从不同的角度阐明了一些问题。事实上，经常发生这样的情况：刚接触工作流的开发人员设计状态机而不是工作流过程。工作流程过程视图主要切换图中框和转换的角色：框是可以更改状态的活动 - 在转换时，工作项可以进入新状态（好吧，这在科学上不正确，但它可能有帮助:-)

对我来说，状态机方面似乎更重要。因此，将您的软件实现为状态机。

是的 - 您应该将所有项目持久保存在数据库中。这就是您保持长时间运行的工作流程运行的方式 - 它们驻留在数据库中，直到被任何活动重新激活为止。所有现成的业务流程管理系统 (BPMS) 都是这样做的。这些工作流程不会保存在内存中。

将所有内容保存在数据库中将使创建报告变得容易。

正如其他人已经提到的，创建一个包含状态信息的新列，甚至创建一个包含元数据的新表：状态，可能是状态更改时的日志，谁更改了状态，有关即将发生的事件的信息（部分已订购）但未交付 - 几天后应有人与供应商核实是否交付已丢失？）。这将使您有机会根据需要添加元数据，而不会影响您的零件数据库。

希望有帮助！

回复收藏 0 原文