sup*_*jos 5 c# state-machine stateless-state-machine
在我正在使用的 C# 解决方案中，应用程序逻辑的核心通过（非常好的）无状态库实现为状态机。对于应用程序显示的不同区域和功能，在许多其他类中建模了业务逻辑的其他部分，但这是推动底层应用程序状态发生主要变化的部分。
尽管每个状态转换本身都非常简单（通知事件、设置 eventArgs、侦听其他事件……）并且我在适用时使用了子状态，但对我来说它开始看起来有点太大了。我知道这不是一个精确的度量，但是如果您查看并考虑子状态，您很可能最终会发现它们本身可能是不同的状态机。
是否有一种明显的方法让我无法使用无状态构建单独的子状态机（可以这么说），将每个状态机映射到不同的类（和文件）？
我想到的第一个阻塞问题是（尤其是第二个）：
在一个大的片上所有的状态变化的状态机触发事件：分裂后，每个单一的国家机器将火每个自己的触发器。所以最好有一个外观收集所有事件并为客户端重新触发它们，以便隐藏许多状态机（毕竟它们是客户端的实现细节）。
无状态子状态负责向上和向下的状态/子状态链的冒泡触发器。因此，例如对于A具有子状态的给定状态，您可以定义一个触发器（在一个地方，A配置），A无论A我们将处于哪个子状态，状态机都会离开。这如何与单独的子状态机一起工作？
小智 3
正如您所提到的，定义好的子状态对于抽象大型状态机的各个部分确实很有帮助。如果您将超级状态及其子状态的定义以及所有防护和进入/退出/转换操作放入其自身的类中，也会很有帮助。
同意您对第 1 点的建议。客户端需要将其视为 1 个状态机。
关于第2点，我建议通过内部触发器在子状态机和超级状态机之间定义一些接口。
我们将您的超级状态机称为A，将子状态机称为B。A将触发诸如StartB之类的事件，该事件会将B从某种空闲状态移动到进行中状态，即运行子状态机。同时A进入某种WaitingForB状态。当B完成其子进程时，它将在A上触发类似BComplete 的事件。然后A将继续其剩余的过程。
您可以让A和B共享同一组可能的触发器，但B也可以定义自己的（较小的）触发器组，或者定义适合其抽象的子流程的级别。我认为，如果B不需要响应与A相同的完整触发器集，那么从整体状态机A中抽象出子状态机B是最有意义的。