通量多个商店实例

Question

在数据按所有者 ID 划分为存储桶的 Flux 应用程序中，我们应该使用一个内部将数据分成存储桶的存储，还是每个存储桶一个存储实例？

例如，我们有一个应用程序用户是多名运动员的教练。每个受过教练的运动员都有零个或多个锻炼，教练可以同时查看一个或多个运动员的锻炼。

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

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

有人对这种方法有任何经验吗？以一种或另一种方式做这件事有什么优点或缺点？或者，哪种方式是“通量方式”，为什么？

Answer 1

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

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

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