Modellazione di eventi ricorrenti

Question

Modellazione di eventi ricorrenti

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Sono in procinto di scrivere un'app Web per tenere traccia delle spese e che sarà multiutente.

Tutto va bene con una sola spesa, ma sto facendo fatica a trovare il modo migliore per rappresentare le spese ricorrenti, cioè le spese di pari importo e categoria che si ripetono regolarmente fino all'annullamento.

Sto pensando di modellare spese ricorrenti come un'istanza di un più generico ExpenseGenerator che come proprietà ha una data di inizio e un modello di frequenza, che quindi creerà automaticamente uno o più Expense s, a partire dalla data di inizio del generatore.

Dato che questo approccio è corretto (in caso contrario, suggerire altre opzioni), non sono sicuro su come attivare la creazione delle spese. Devo creare qualcosa come un cronjob che crea la nuova spesa non appena si verifica o controlla lo stato del generatore ogni volta che un utente effettua il login?

Entrambe le soluzioni hanno qualche problema:

Cronjob: questo creerà un lavoro per ogni spesa esistente di ciascun utente esistente, inoltre dovrei occuparmi di diversi fusi orari, ora legale e così via.
Creazione all'accesso: se l'utente non effettua l'accesso per un lungo periodo, potrebbero esserci molte spese da creare.

Sto andando nella direzione giusta o c'è un approccio più efficiente per modellare eventi ricorrenti e risolvere tutti questi problemi?

design-patterns web-applications domain-model scheduling backend

posta Vektor88 10.11.2018 - 13:05

fonte

3 risposte

1

Supponiamo che un utente configuri spese ricorrenti e non acceda mai dopo. Qual è il comportamento che vuoi? Le spese devono essere automaticamente presentate e rimborsate oppure l'utente deve accedere per approvare o confermare spese ricorrenti?

Queste non sono domande sulla rappresentazione di modellazione e sull'efficienza di esecuzione, ma piuttosto domande da porre a livello del dominio aziendale e dei suoi stakeholder. Quando lo hai ordinato, puoi passare all'implementazione.

risposta data 10.11.2018 - 16:54

fonte

1

Quando si crea una spesa, basta contrassegnarla come ricorrente con un'opzione della frequenza. Un lavoro batch giornaliero può quindi interrogare tutte le spese passate UNICHE che dovrebbero ripetersi oggi e crearle.

Ultimo mercoledì = > Crea titolo di spesa: "Pay Utility bill" Frequenza: settimanale, Id: 7

Questa settimana mercoledì = > Seleziona Spese dove Timestamp + Frequenza = Oggi (Dovrebbe riportare 7) Crea spesa "Fattura conto pagamento" Frequenza - Settimanale - Id 34

Settimana prossima mercoledì = > Seleziona Spese dove Timestamp + Frequenza = Oggi (Dovrebbe riportare 34) Crea il titolo di spesa: "bolletta Paga", frequenza: settimanale, id: 48

risposta data 11.11.2018 - 06:47

fonte

Leggi altre domande sui tag design-patterns web-applications domain-model scheduling backend

Esiste un'alternativa valida alle intestazioni HTTP per l'invio di credenziali di autenticazione In che modo Haskell limita gli effetti collaterali?

score 3 · Accepted Answer

Suppongo che tu stia monitorando le spese verificatesi (in passato) e le spese non pianificate (in futuro).

L'approccio del generatore di spesa va bene:

tieni traccia di tutte le spese ricorrenti in una raccolta (o in una tabella speciale), ordinate per data della prossima occorrenza;
ogni volta che il generatore viene eseguito, deve passare attraverso la raccolta fino a quando non raggiunge la data di oggi. Per ogni oggetto corrispondente:
- crea il Expense reale con la data dell'occorrenza;
- calcola la prossima data di occorrenza e inserisci l'elemento aggiornato nella raccolta (in modo che lo stesso articolo possa essere elaborato più volte), a meno che non venga raggiunta la data di fine (se presente).

Poiché hai un'applicazione web, la cosa più semplice è che l'app esegua il generatore ogni giorno (ad ogni avvio per gestire immediatamente qualsiasi arretrato non previsto, e poi ogni giorno in base a un evento del timer), e sempre per ogni utente. Se si dispone di molti utenti, l'elaborazione potrebbe essere distribuita su un periodo più lungo se eseguita in un thread separato. Prestare tuttavia attenzione alla coerenza in caso di attività dell'utente (ad esempio, cancellazione delle spese che hanno un evento successivo nel passato o nello stesso giorno), soprattutto se si dispone dei requisiti 24/24 a causa di un ampio insieme di fusi orari.

Anche l'opzione di elaborare le spese su richiesta potrebbe essere considerata. Tuttavia, fallo solo se è giustificato, in particolare se c'è un alto rischio di avere molti utenti fantasma che inquinano il tuo database con account non utilizzati. Eviterei lo scenario di accesso il più possibile, perché:

rischio più elevato di ritardi dovuti all'elaborazione del backlog al login
se l'elaborazione del backlog viene eseguita in un thread separato, i dati potrebbero essere aggiornati mentre l'utente sta lavorando, mostrando un'immagine incoerente / incompleta dell'account ("wow! Ho $ 1000 rimasti! Oops, no, finalmente è solo $ 200 ").
Cosa succede se un utente delega i diritti di accesso anche a un altro utente?
ma soprattutto non è possibile evolvere in uno stile push di applicazioni, con notifiche per l'utente quando non è stato effettuato l'accesso.