在数据按所有者 id 分为桶的通量应用程序中，我们应该使用一个内部将数据分成桶的存储，还是每个桶一个存储实例？
例如，我们有一个应用程序用户，他是多名运动员的教练。每位受训运动员都有零个或多个训练，教练可以同时查看一个或多个运动员的训练。
我们可以为所有运动员开设一家健身器材店；store 必须确保所有数据都被分离到 athlete 桶中，并且每个 store 方法都需要一个 athleteId 参数。
或者，我们可以为每个运动员 ID 设置一个商店实例。这简化了存储逻辑和方法签名，但是我们必须管理更多存储实例。
有没有人有这种方法的经验？以一种或另一种方式做这件事有什么好处或坏处吗？或者，哪种方式是“通量方式”，为什么？
Flux 的方式是创建单例存储。它们不是模型，因为我们习惯于在 ORM 风格的 MVC 模式中考虑模型。存储仅在应用程序初始化时实例化。他们管理逻辑和数据的“域”。
这些单例存储向调度程序注册回调。回调是数据进入商店的唯一途径。商店还提供 getter 方法作为公共 API —— 数据获取的唯一途径。没有二传手。商店是一个自己的世界，完全控制他们的数据和行为。
在您的情况下，听起来逻辑域是 Athlete 和 Workout，所以我将创建一个 AthleteStore 和一个 WorkoutStore，并在各自的商店中维护这两个东西的集合。例如，我想你会有像 一样的吸气剂getWorkoutsByAthleteID()。