为什么在 Flux 应用程序架构中每个实体使用一个存储？

我正在一个项目中使用reactjs 和flux 架构。我对如何将嵌套数据正确分解为存储以及为什么我应该将数据拆分为多个存储感到有点困惑。

为了解释这个问题，我将使用这个例子：

想象一个有项目的 Todo 应用程序。每个项目都有任务，每个任务都可以有注释。

该应用程序使用 REST api 检索数据，返回以下响应：

{
    projects: [
        { 
            id: 1, 
            name: "Action Required",
            tasks: [
                {
                    id: 1,
                    name: "Go grocery shopping",
                    notes: [
                        {
                            id: 1,
                            name: "Check shop 1"
                        },
                        {
                            id: 2,
                            name: "Also check shop 2"
                        }
                    ]
                }
            ]
        },
    ]
}

虚构应用程序的界面在左侧显示项目列表，当您选择一个项目时，该项目将变为活动状态，并且其任务将显示在右侧。当您单击任务时，您可以在弹出窗口中看到其注释。

我要做的是使用 1 个商店，即“项目商店”。操作向服务器发出请求，获取数据并指示存储用新数据填充自身。商店在内部保存该实体树（项目 -> 任务 -> 注释）。

为了能够根据选择的项目显示和隐藏任务，我还在商店中保留一个变量“activeProjectId”。基于此，视图可以获取活动项目、其任务并渲染它们。

问题解决了。

但是：在网上搜索了一下这是否是一个好的解决方案后，我看到很多人说您应该为每个实体使用单独的商店。

这意味着： ProjectStore、TaskStore 和 NoteStore。为了能够管理关联，我可能还需要“TasksByProjectStore”和“NotesByTaskStore”。

有人可以解释一下为什么这样会更好吗？我唯一看到的是管理存储和数据流的大量开销。

使用一家商店或不同商店各有利弊。可以这么说，flux 的某些实现特别支持一个存储来统治所有存储，而其他实现也有利于多个存储。

一家商店还是多家商店适合您的需求，取决于 a) 您的应用程序的功能，以及 b) 您期望的未来发展或变化。简而言之：

• 一间店如果您主要关心的是嵌套实体之间的依赖关系，则更好。如果您不太担心服务器存储组件之间的单个实体关系之间的依赖关系。一家商店就很棒，例如您想要在项目级别管理有关基础任务和注释的统计信息。许多类似父子关系和从服务器获取一体式数据的方式都支持一种商店解决方案。
• 多家门店如果您主要关心的是服务器存储组件之间的单个实体连接之间的依赖关系，那就更好了。弱的实体到实体关系和独立的单个实体服务器获取和更新有利于多个存储。

就你而言：我敢打赌，一家商店会更好。您具有明显的父子关系，并从服务器一次获取所有项目数据。

稍微长一点的答案：

一间店:

• 非常适合最大限度地减少管理多个商店的开销。
• 如果您的顶视图组件是唯一有状态组件，并且从存储中获取所有数据，并将详细信息分发给无状态子组件，那么它会很好地工作。
• 但是，管理实体之间的依赖关系的需要并不会简单地消失：您需要在单个商店内管理它们，而不是在不同商店之间管理它们。因此变得更大（更多行代码）。
• 此外，在典型的通量设置中，每个存储都会发出一个“我已更改”事件，并将其留给组件来确定更改的内容以及是否需要顶部重新渲染。因此，如果您有许多嵌套实体，并且其中一个实体从服务器接收到许多更新，那么您的超级存储会发出许多更改，这可能会触发整个结构和所有组件的大量不必要的更新。 Flux-react 可以处理很多事情，并且细节更改更新一切都是它处理得很好的，但它可能无法满足每个人的需求（当它搞砸了一个项目中状态之间的转换时，我不得不放弃这种方法）。

多家门店:

• 是的，更多的开销，但对于某些项目，您也可以获得回报
• 如果服务器数据和组件之间存在紧密耦合，并且中间有通量存储，则更容易将关注点分离到单独的存储中
• 如果例如您期望对笔记数据结构进行许多更改和更新，这比拥有一个有状态的笔记组件更容易，该组件监听笔记存储，然后处理来自服务器的笔记数据更新。当处理笔记结构的变化时，您可以只关注笔记存储，而不需要弄清楚在一些大型超市中笔记是如何处理的。