为什么在通量应用程序架构中每个实体使用一个商店?

IT技术 javascript reactjs reactjs-flux flux
2021-05-24 09:50:26

我在我正在从事的项目中使用 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”。

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

1个回答

使用一家商店或不同的商店有利有弊。可以这么说,某些flux 的实现特别倾向于一个商店来统治所有商店,而其他的也促进多个商店。

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

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

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

稍微长一点的答案:

一店

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

多家门店

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