在我正在使用的C#解决方案中,应用程序逻辑的核心是通过(非常好的)
Stateless库实现为状态机.对于应用程序显示的不同区域和功能,还有许多其他类建模的业务逻辑的其他部分,但这是推动基础应用程序状态的主要变化的部分.

虽然每个状态转换本身都非常简单(通知事件,设置eventArgs,监听其他事件,……)并且我在适用时使用子状态,但对于我来说它开始看起来有点太大了.我知道这不是一个准确的衡量标准,但是如果你看一下并考虑子状态,你最终可能会发现它们可能是独立的状态机.

有没有一种明显的方法,我缺少用Stateless构建单独的子状态机(也就是说),将每个状态机映射到一个不同的类(和文件)？

我想到的第一个阻塞问题是(特别是第二个)：

>一个大件状态机触发所有状态更改的事件：在拆分后,每个单个状态机将触发每个自己的触发器.所以最好是收集所有事件并为客户端重新触发它们的façade,以便隐藏许多状态机(毕竟它们是客户端的实现细节).
>无状态子状态处理状态/子状态链上的冒泡触发,以及向下.所以例如对于具有子状态的给定状态A,可以定义一个触发器(在一个地方,A的配置),它将使状态机离开A,无论我们将在哪个A子状态.这如何与单独的子状态机一起使用？

最佳答案 正如您所提到的,定义好的子状态对于能够抽象大型状态机的各个部分非常有帮助.如果你把一个超状态的定义及其子状态加上所有的守卫和进入/退出/转换动作放在一个自身的类中,这也会很有帮助.

同意您对第1点的建议.客户需要将其视为1状态机.

关于第2点,我建议通过内部触发器在子状态机和超级状态机之间定义一些接口.

让我们调用你的超级状态机A和你的子状态机B.A会触发一个事件,比如StartB,它会将B从某种空闲状态移动到InProgress状态,即运行子状态机.同时A进入某种WaitingForB状态.当B完成其子进程时,它将在A上触发类似BComplete的事件.然后,A将继续其余的进程.

你可以让A和B共享同一组可能的触发器,但是B也可以定义它自己的(较小的)触发器集,或者在适合它抽象的子进程的级别上.我认为,如果B不需要响应与A相同的完整触发器集,那么从一个大件状态机A中抽取子状态机器B是最有意义的.