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