在我正在使用的C＃解决方案中，应用程序逻辑的核心是通过（非常好的）Stateless库实现为状态机。对于应用程序显示的不同区域和功能，还有许多其他类建模的业务逻辑的其他部分，但这是推动基础的主要变化的那个部分app状态。
虽然每个状态转换本身都非常简单（通知事件，设置eventArgs，监听其他事件，......）并且我在适用时使用子状态，但对于我来说它开始看起来像某种方式
我是否有一种明显的方法可以用Stateless构建单独的子状态机（也就是说），将每个状态机映射到 distinct 类（和文件）？ 我想到的第一个阻塞问题是（特别是第二个）： one-big-piece 状态机触发所有状态更改的事件：在拆分后，每个单个状态机将触发每个自己的触发器。所以最好是收集所有事件并为客户端重新触发它们的façade，以便隐藏许多状态机（毕竟它们是客户端的实现细节）。 无状态子状态处理冒泡触发状态/子状态链，以及向下。所以例如对于具有子状态的给定状态
A，可以定义一个触发器（在一个地方，A的配置），这将使状态机离开A，无论在哪个子状态A我们会的。如何使用单独的子状态机？
答案 0 :(得分：2)
正如您所提到的，定义好的子状态对于能够抽象大型状态机的各个部分非常有帮助。如果你把一个超状态的定义及其子状态加上所有的守卫和进入/退出/转换动作放在一个自身的类中，这也会很有帮助。
同意您对第1点的建议。客户需要将其视为1状态机。
关于第2点，我建议通过内部触发器在子状态机和超级状态机之间定义一些接口。
让我们调用您的超级状态机 A 和您的子状态机 B 。 A 会触发 StartB 等事件，将 B 从某种空闲状态移动到 InProgress 状态，即运行子状态机。同时 A 进入某种 WaitingForB 状态。当 B 完成其子进程时，它将在 A 上触发 BComplete 之类的事件。 A 将继续其余的过程。
您可以让 A 和 B 共享同一组可能的触发器，但 B 也可以定义自己的（较小的）一组触发器或在适合其抽象的子进程的级别上。我认为从一大块状态机 A 中抽取子状态机器 B 是最合理的，如果 B < / em>不需要像 A 那样响应相同的完整触发器。