通量多存储实例 [英] flux multiple store instances

问题描述

在数据按所有者 id 分为多个桶的通量应用程序中，我们应该使用一个内部将数据分成多个桶的存储，还是每个存储桶一个存储实例?

In a flux application where data is divided into buckets by owner id, should we use one store which internally separates the data into buckets, or one store instance per bucket?

例如，我们有一个应用程序用户，他是多名运动员的教练.每位受训运动员都有零次或多次训练，教练可以同时查看一名或多位运动员的训练.

For instance, we have an application user who is a coach for multiple athletes. Each coached athlete has zero or more workouts, and the coach can view one or more athletes' workouts at the same time.

我们可以为所有运动员开设一家健身商店；store 必须确保所有数据都被分到 athlete 桶中，并且每个 store 方法都需要一个 athleteId 参数.

We could have one workout store for all athletes; the store has to ensure that all data is separated into athlete buckets, and every store method requires an athleteId parameter.

或者，我们可以为每个运动员 ID 设置一个商店实例.这简化了存储逻辑和方法签名，但随后我们必须管理更多存储实例.

Or, we could have one store instance per athlete id. This simplifies the store logic and method signatures, but then we have to manage more store instances.

有人对这种方法有经验吗?以一种或另一种方式做有什么优点或缺点吗?或者，哪种方式是通量方式"，为什么?

Does anybody have any experience with this approach? Any pros or cons of doing it one way or the other? Or, which way is 'the flux way', and why?

推荐答案

Flux 的方式是创建单例存储.它们不是模型，因为我们习惯于在 ORM 风格的 MVC 模式中考虑模型.存储仅在应用程序初始化时实例化.他们管理逻辑和数据的域".

The Flux way is to create singleton stores. They are not models as we are used to thinking about models in an ORM-style MVC pattern. Stores are instantiated only at the moment of the application's initialization. They manage a "domain" of logic and data.

这些单例存储向调度程序注册一个回调.回调是数据进入商店的唯一途径.Stores 还提供 getter 方法作为公共 API——数据获取的唯一途径.没有二传手.商店是自己的世界，完全可以控制他们的数据和行为.

These singleton stores register a callback with the dispatcher. The callback is the only way data gets into the stores. Stores also provide getter methods as a public API -- the only way data gets out. There are no setters. Stores are a universe of their own, completely in control of their data and behavior.

在您的情况下，听起来逻辑域是 Athlete 和 Workout，所以我将创建一个 AthleteStore 和一个 WorkoutStore，并在它们各自的商店中维护这两个东西的集合.例如，我想你会有像 getWorkoutsByAthleteID() 这样的 getter.

In your case, it sounds like the logical domains are Athlete and Workout, so I would create an AthleteStore and a WorkoutStore, and maintain collections of those two things within their respective stores. I'd imagine you'll have getters like getWorkoutsByAthleteID(), for example.

这篇关于通量多存储实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！