我开发的应用程序最初是使用 Flux 构建的。

但是，随着时间的推移，应用程序变得越来越难以维护。有非常大量的操作。通常一个 Action 只能在一个地方(商店)听到。

操作使得不必在一个地方编写所有事件处理程序代码成为可能。所以代替这个:

store.handleMyAction('ha') 
another.handleMyAction('ha') 
yetAnotherStore.handleMyAction('ha') 

我可以写:

actions.myAction('ha') 

但是我从不以这种方式使用操作。我几乎可以肯定，这不是我的应用程序的问题。

每次调用操作时，我都可以调用 store.onSmthHappen 而不是 action.smthHappen。

当然也有异常(exception)，即一个操作在多个地方处理。但当这种情况发生时，感觉好像出了什么问题。

如果我不直接从商店调用方法而不是调用操作，怎么样？我的申请会不会这么灵活？不!仅重命名发生(极少数异常(exception))。但代价是什么!通过所有这些操作，理解应用程序中发生的情况变得更加困难。每次，当跟踪复杂 Action 的处理时，我都必须在处理它们的商店中查找。然后在这些商店中我应该找到调用另一个操作的逻辑。等等。

现在我提出我的解决方案:

有些 Controller 直接从存储中调用方法。 如何处理操作的所有逻辑都在商店中。还存储对 WebAPI 的调用(通常一个存储与一个 WebAPI 相关)。如果事件应该在多个存储中处理(通常顺序)，则 Controller 通过编排从存储返回的 promise 来处理此问题。一些序列(常用)在其自身的私有(private)方法中。 Controller 的方法可以将它们用作处理的简单部分。所以我将永远不会重复代码。

Controller 方法不返回任何内容(单向流)。

事实上， Controller 不包含如何处理数据的逻辑。它只是在哪里以及以什么顺序。

您几乎可以在 Store 中看到数据处理的全貌。商店中没有关于如何与其他商店交互的逻辑(对于 Flux，它就像多对多关系，但只是通过操作 )。现在store是一个高度内聚的模块，只负责领域模型(集合)的逻辑。

flux 的主要(在我看来)优势仍然存在。

因此，商店是唯一真正的数据来源。组件可以订阅商店。组件调用与以前相同的方法，但使用 controller 代替 actions。与 React 的交互根本没有改变。

此外，事件处理变得更加明显。现在我只需查看 Controller 中的处理程序，一切就变得清晰起来，并且调试起来更加容易。

问题是:

为什么 Action 是不断变化的？我错过了他们的哪些优点？

请您参考如下方法:

实现的操作是为了捕获 View 上或服务器上的特定交互，然后可以将其分派(dispatch)到任意数量的不同商店。开发人员用 facebookchat 的例子解释了这一点。 有一个消息存储和一个线程存储。当 Action 例如。 messagePost 被发出，它被分派(dispatch)到两个存储中，执行不同的工作来更新它们的属性。 Threadstore 增加了未读消息的数量，messageStore 将新消息添加到其消息数组中。

因此，它基本上是引导一项操作在多个商店中执行数据更改。