在通过所有者ID将数据划分为存储桶的通量应用程序中，我们是否应该使用一个内部将数据分隔为存储区的存储区，或者每个存储区一个存储实例？
例如，我们有一名申请用户，他是多名运动员的教练。每个执教的运动员都有零次或多次训练，教练可以观看一名或多名运动员。同时训练。
我们可以为所有运动员提供一个健身商店;商店必须确保将所有数据分成运动员桶，并且每个商店方法都需要运动员参数。
或者，我们每个运动员身份可以有一个商店实例。这简化了商店逻辑和方法签名，但随后我们必须管理更多商店实例。
有没有人有这种方法的经验？以某种方式做到这一点的任何利弊？或者，通道方式是什么？为什么？
答案 0 :(得分：8)
Flux方式是创建单身商店。它们不是模型，因为我们习惯于在ORM风格的MVC模式中思考模型。存储仅在应用程序初始化时实例化。他们管理一个＆＃34;域＆＃34;逻辑和数据。
这些单件商店向调度员注册回调。回调是数据进入商店的唯一方式。商店还提供getter方法作为公共API - 数据输出的唯一方式。没有制定者。商店是他们自己的宇宙，完全控制他们的数据和行为。
在你的情况下，听起来逻辑领域是运动员和锻炼，所以我会创建一个AthleteStore和一个WorkoutStore，并在他们各自的商店内维护这两件事的集合。我想你会像getWorkoutsByAthleteID()那样拥有吸气剂。