为啥在通量应用程序架构中每个实体使用一个商店？

Posted 2023-02-22

【中文标题】为啥在通量应用程序架构中每个实体使用一个商店？

【英文标题】：Why use one store per entity in the flux application architecture?为什么在通量应用程序架构中每个实体使用一个商店？

【发布时间】：2016-01-11 11:08:41

【问题描述】：

我正在一个项目中使用 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”。

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

【参考方案1】：

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

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

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

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

稍长一点的答案：

一个商店：

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

多家商店：

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

【讨论】：

我今天意识到我从来没有评论过你的回答。谢谢，我最终使用了单个商店，因为应用程序不是很复杂。