Поток нескольких экземпляров хранилища

В приложении потока, где данные делятся на ведра по идентификатору владельца, следует ли использовать одно хранилище, которое внутренне разделяет данные в ведрах или один экземпляр хранилища на каждый ведро?

Например, у нас есть пользователь приложения, который является тренером для нескольких спортсменов. У каждого тренируемого спортсмена есть ноль или более тренировок, и тренер может одновременно наблюдать за одной или несколькими тренировками спортсменов.

У нас может быть один магазин для тренировок для всех спортсменов; магазин должен обеспечить, чтобы все данные были разделены на ведра атлета, и для каждого метода хранения требуется параметр athleteId.

Или, у нас может быть один экземпляр магазина для идентификатора спортсмена. Это упрощает логику и логику хранилища, но тогда нам нужно управлять большим количеством экземпляров хранилища.

Есть ли у кого-нибудь опыт такого подхода? Любые плюсы или минусы делают это так или иначе? Или, каким образом это "поток потока" и почему?

ОТВЕТЫ

Ответ 1

Путь Flux - создавать хранилища одноэлементных. Они не являются моделями, поскольку мы привыкли думать о моделях в шаблоне MVC в стиле ORM. Магазины создаются только в момент инициализации приложения. Они управляют "доменом" логики и данных.

Эти хранилища singleton регистрируют обратный вызов с диспетчером. Обратный вызов - это единственный способ получить данные в магазинах. Магазины также предоставляют методы getter как публичный API - единственный способ получить данные. Нет сеттеров. Магазины - это вселенная, полностью контролирующая их данные и поведение.

В вашем случае это звучит так, как логические домены - это Athlete and Workout, поэтому я бы создал AthleteStore и WorkoutStore и поддерживал коллекции этих двух вещей в своих магазинах. Я бы предположил, что у вас будут такие источники, как getWorkoutsByAthleteID(), например.