istanze di più negozi di flusso

Question

In un'applicazione di flusso in cui i dati sono suddivisi in bucket per ID proprietario, dovremmo utilizzare un archivio che separa internamente i dati in bucket o un'istanza di archivio per bucket?

Ad esempio, abbiamo un utente dell'applicazione che è un allenatore per più atleti. Ogni atleta allenato ha zero o più allenamenti e l'allenatore può visualizzare contemporaneamente uno o più allenamenti degli atleti.

Potremmo avere un negozio di allenamento per tutti gli atleti; lo store deve garantire che tutti i dati siano separati in bucket di atleti e che ogni metodo di store richieda un parametro athleteId.

Oppure, potremmo avere un'istanza negozio per ID atleta. Questo semplifica la logica del negozio e le firme dei metodi, ma poi dobbiamo gestire più istanze di negozio.

Qualcuno ha esperienza con questo approccio? Qualunque pro o contro di farlo in un modo o nell'altro? O, in che modo è "la via del flusso" e perché?

Answer 1

Il modo Flusso è creare negozi singleton. Non sono modelli in quanto siamo abituati a pensare ai modelli in un pattern MVC in stile ORM. I negozi vengono istanziati solo al momento dell'inizializzazione dell'applicazione. Gestiscono un "dominio" di logica e dati.

Questi negozi singleton registrano una richiamata con il dispatcher. Il callback è l'unico modo in cui i dati arrivano nei negozi. I negozi forniscono anche metodi getter come API pubblica - l'unico modo in cui i dati escono. Non ci sono setter. I negozi sono un universo tutto loro, completamente in controllo dei loro dati e comportamenti.

Nel tuo caso, sembra che i domini logici siano Atleta e Allenamento, quindi creerò un AthleteStore e un WorkoutStore e manterrai le raccolte di queste due cose nei rispettivi negozi. Immagino che avrai getter come getWorkoutsByAthleteID(), per esempio.