flux多个商店实例

Question

在一个flux应用程序中，通过所有者id将数据分为多个存储区，我们是否应该使用一个内部将数据分成多个存储区的存储区或每个存储区一个存储区实例？

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

我们可以为所有运动员提供一个健身房;商店必须确保将所有数据分成运动员桶，并且每个商店方法都需要运动员ID参数。

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

有没有人有这种方法的经验？任何以这样或那样的方式进行的优点或缺点？或者，哪种方式是“流动方式”，为什么？

Answer 1

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

这些单件商店向调度员注册回调。回调是数据进入商店的唯一方式。商店还提供getter方法作为公共API--数据传播的唯一途径。没有二传手。商店是他们自己的世界，完全控制着他们的数据和行为。

就你而言，听起来像是运动员和锻炼的逻辑域，所以我会创建一个AthleteStore和一个WorkoutStore，并在它们各自的商店中维护这两件事的集合。例如，我想像你会得到像getWorkoutsByAthleteID()这样的获得者。