Come si fa un evento ricorrente? Come una voce in un ordine del giorno

Questo è il momento in cui la separazione dell'interfaccia dall'implementazione è importante. La tua interfaccia dovrebbe gestire il terzo venerdì di ogni mese e peggio (il 3 ° venerdì di ogni mese eccetto il passaggio al giorno lavorativo successivo in cui entrambe le parti concordano un giorno lavorativo basato sulla tabella delle festività per la regione in cui è incorporata l'attività) , ma dovresti solo implementare i casi che sono reali in questo momento.

Quindi creo un'interfaccia scheduler che può essere passata per un periodo di tempo, e lo scheduler può riempire il periodo di tempo con istanze quando lo dici a. La logica di come farlo risiede nell'oggetto dello scheduler.

Per quanto riguarda il cron job - puoi usare questo design e avere un cron job che crea nuove istanze, ma potresti trovarti semplicemente non ne ha bisogno. Potrebbe essere utile fare qualcosa come il job cron se hai bisogno di scrivere una query del database contro le istanze e non ti interessa la logica della pianificazione che le ha create. Se il cron job viene eseguito abbastanza velocemente, potresti essere in grado di attivare il lavoro ogni volta che hai bisogno che i dati siano aggiornati, invece di usare cron.

Ero con te fino alla parte in cui hai menzionato la memorizzazione di "istanze" usando un cronjob. Ovviamente ogni dominio ha requisiti diversi, ma ho scoperto che il più delle volte il modo più semplice ed efficace per gestire eventi ricorrenti è di essere ottimista e persistere delle variazioni.

Con questo intendo che hai un evento / notifica / evento ricorrente con una data di inizio, una data di fine e una frequenza. Solo questa singola entità consente di disegnare le istanze nell'interfaccia utente. L'unica volta in cui è necessario mantenere le informazioni di istanza è se qualcuno annulla una data specifica o fa una nota per una data specifica o altro. Quindi il tuo evento ricorrente può avere raccolte di cancellazioni, note e altre entità per date specifiche (istanze). Ciò consente di disegnare correttamente l'interfaccia utente senza avere un'entità persistente per ciascuna istanza di evento ricorrente. Naturalmente avrai bisogno della logica di business per assicurarti che il tuo evento ricorrente non abbia una cancellazione o altre informazioni di istanza per una data in cui l'evento non si verificherà.

Fammi sapere se questo ha un senso o se hai bisogno di altri chiarimenti.

Modifica

Ho implementato tali funzionalità persistendo i "Dismissals" e "Sent Mail" in raccolte separate per ogni dato evento. Cioè, quando un utente fa clic per chiudere una notifica che registra nel database che la notifica per il 16/05/2012 è stata letta in modo tale che tu sappia di non disegnarla nell'interfaccia utente.

Come sottolineato da psr, fare tutti questi calcoli può penalizzare le prestazioni. Ho riscontrato, tuttavia, che non è un problema in nessuno dei miei programmi perché i database sono molto veloci e il periodo di tempo più lungo che stai guardando è solitamente un mese o alcuni mesi. Inoltre, penso che mantenga il tuo modello molto più pulito perché non devi preoccuparti di creare e distruggere istanze nel database in ogni momento nei casi in cui un evento si ripresenterà indefinitamente o l'utente cambierà le date di inizio e fine. p>

Detto questo, avrai bisogno di un'attività programmata per inviare regolarmente le email. L'attività può guardare per vedere quali eventi stanno arrivando e quali hanno email che sono già state inviate per capire quali email inviare.