【发布时间】:2015-05-13 17:56:51
【问题描述】:
在我正在使用的 C# 解决方案中,应用程序逻辑的核心通过(非常好)Stateless 库实现为状态机。对于应用程序显示的不同区域和功能,业务逻辑的其他部分在许多其他类中建模,但这是推动底层主要变化的因素应用状态。
虽然每个状态转换本身都非常简单(通知事件、设置 eventArgs、侦听其他事件……)并且我在适用时使用子状态,但对我来说它开始看起来像 不知何故 em>太大了。我知道这不是一个精确的衡量标准,但是如果您仔细考虑子状态,您最终可能会发现它们本身可能是不同的状态机。
我是否缺少一种明显的方式来构建单独的 sub-statemachine(可以这么说)与 Stateless,将每个状态机映射到一个 distinct 类(和文件)?
我想到的第一个阻塞问题是(尤其是第二个):
one-big-piece 状态机在所有状态更改时触发事件:拆分后,每个单独的状态机将触发各自的触发器。所以最好有一个外观来收集所有事件并为客户端重新触发它们,以便隐藏许多状态机(毕竟它们是客户端的实现细节)。
无状态子状态负责冒泡触发状态/子状态链向上以及向下。所以例如对于具有子状态的给定状态
A,可以定义一个触发器(在一个地方,A的配置),这将使状态机离开A,无论我们将处于A的哪个子状态.这如何与单独的子状态机一起使用?
【问题讨论】:
-
关于问题 #2,至少对于 exiting:可以认为子状态机
B可能具有 disabled 或 inactive 每次 parent 机器指示退出状态B时进入的状态。
标签: c# state-machine stateless-state-machine