为什么在flux应用程序体系结构中每个实体使用一个商店？

Question

我在我正在研究的项目中使用reactjs和助焊剂架构。我对如何将嵌套数据正确地拆分到存储中以及为什么应该将数据拆分到多个存储中感到困惑。

为了说明问题，我将使用以下示例：

想象一下您有项目的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”。

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

Answer 1

使用一个商店或不同商店各有利弊。可以这么说，有些通量实现特别有利于一家商店来统治所有商店，而其他一些实现还促进了多个商店。

一个商店还是多个商店满足您的需求，取决于a）您的应用程序做什么，以及b）您期望的未来发展或变化。简而言之：

• __如果您最关心的是嵌套实体之间的依赖关系，那么 一家商店 会更好。并且如果您不太担心服务器存储组件之间的单个实体关系之间的依赖性。如果例如您要在项目级别管理有关基础任务和注释的统计信息，那么一家商店就很好。许多类似父子关系和从服务器中获取数据的多合一方法更倾向于一种存储解决方案。
• __如果您最关心的是服务器存储组件之间的单个实体连接之间的依赖性，则最好使用 多个存储 。实体与实体之间的关系较弱，以及独立的单个实体服务器的访存和更新有利于多个存储。

在您的情况下：我敢打赌，一家商店会更好。您具有明显的父子关系，并立即从服务器获取所有项目数据。

答案更长一些：

一间商店 ：

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

多家商店 ：

• 是的，更多的开销，但是对于某些项目，您也可以获得回报
• 如果您在服务器数据和组件之间建立了紧密的联系，并且流量存储在两者之间，则将关注点分离到单独的存储中会更容易
• 例如，如果您希望对Notes数据结构进行许多更改和更新，那么拥有一个有状态的Notes组件比侦听Notes存储器更容易，该组件便会处理来自服务器的Notes数据更新。在处理便笺结构中的更改时，您可以只关注便笺存储，而无需弄清楚在大型大型超市中如何处理便笺。