通量存储或操作(或两者)应该触及外部服务吗？

我已经看到了通量模式的两种实现方式，并且在我自己完成了这两种方式(最初采用前一种方式)之后，我相信存储应该是来自动作的数据的哑接收者，而且写入的异步处理应该存在于动作创建者中。(Async reads can be handled differently)根据我的经验，这样做有几个好处，按重要性排序:

1. 您的存储变得完全同步。这使您的存储逻辑更容易跟踪，也更容易测试ーー只需用某个给定的状态实例化一个存储，向它发送一个操作，然后检查状态是否按照预期发生了变化。此外，流动中的核心概念之一是防止级联分派和一次防止多个分派; 当存储进行异步处理时，这是非常困难的。

2. 所有动作分派都是从动作创建者发生的。如果您处理存储中的异步操作，并且希望保持存储的操作处理程序同步(为了获得通量单分派保证，您应该这样做) ，那么您的存储将需要触发额外的 SUCCESS 和 FAIL 操作来响应异步处理。将这些调度放在动作创建器中反而有助于分离动作创建器和存储器的作业; 此外，您不必深入挖掘存储器逻辑来确定从哪里调度动作。在这种情况下，典型的异步操作可能类似于下面这样(根据所使用的通量类型更改 dispatch调用的语法) :

   someActionCreator: function(userId) {
   // Dispatch an action now so that stores that want
   // to optimistically update their state can do so.
   dispatch("SOME_ACTION", {userId: userId});
   
   
   // This example uses promises, but you can use Node-style
   // callbacks or whatever you want for error handling.
   SomeDataAccessLayer.doSomething(userId)
   .then(function(newData) {
   // Stores that optimistically updated may not do anything
   // with a "SUCCESS" action, but you might e.g. stop showing
   // a loading indicator, etc.
   dispatch("SOME_ACTION_SUCCESS", {userId: userId, newData: newData});
   }, function(error) {
   // Stores can roll back by watching for the error case.
   dispatch("SOME_ACTION_FAIL", {userId: userId, error: error});
   });
   }
   

   可能在不同操作之间重复的逻辑应该提取到一个单独的模块中; 在本例中，该模块将是 SomeDataAccessLayer，它处理实际的 Ajax 请求。

3. 你需要更少的行动创造者。这没什么大不了的，但是拥有它是件好事。正如在 # 2中提到的，如果您的存储具有同步操作分派处理(并且它们应该具有同步操作分派处理) ，那么您将需要触发额外的操作来处理异步操作的结果。在操作创建器中执行分派意味着单个操作创建器可以通过处理异步数据访问本身的结果来分派所有三种操作类型。