Recentemente, ho provato a costruire un sistema di notifica, ma ho subito notato che le notifiche sono cose complicate, specialmente nel contesto della costruzione di un modello generale. La diversità di ciò che li innesca (da un clic su un pulsante a qualcosa che termina, "azioni" come li chiamerò), a chi deve essere notificato, e persino a quale tipo di messaggio inviare mandare un sistema estremamente flessibile per definire e gestire loro.
Ho visto molte soluzioni a favore di un approccio "attivo", in cui gli eventi che generano le notifiche stesse li creano. Tuttavia, nella mia mente, questo è l'equivalente di un tostapane difettoso che comunica ai servizi di emergenza che ha dato il via a un incendio.
La metafora si applica sia in termini di intervento attivo da parte dell'attore, che decentralizza le notifiche (aspetta, quali parti del codice creano nuovamente le notifiche, e quando succede?), oltre a confondere le responsabilità delle parti del sistema generale, dando molta energia alle azioni che dovrebbero concentrarsi su, bene, agire.
D'altro canto, è completamente intrattabile analizzare tutti gli effetti collaterali di ogni azione e decidere quale notifica generare. Inoltre, la relazione non è necessariamente one-to-one: le azioni potrebbero in teoria generare più notifiche di tipi diversi, destinate a più utenti.
Tuttavia, la modifica persistente dello stato - nella maggior parte dei casi, un database, e nella mia, MySQL - è il punto cruciale di molte di queste azioni, e ho cercato di sfruttare questo per creare un sistema di notifica che può essere sia passivo che generale. L'essenza è la seguente:
- Tutte le azioni ereditano da una classe
Actionche serve esclusivamente a pacchettizzare la parte "recitazione" e ad attivare l'elaborazione delle notifiche. - Durante l'esecuzione dell'azione, vengono registrate tutte le query del database.
- Una volta terminata l'esecuzione, le notifiche, ognuna delle quali elenca le loro dipendenze nel database (quali valori potrebbero causare loro spawn), vengono prima filtrate con un'espressione booleana specifica per la notifica nell'elenco delle tabelle / colonne che sono state modificate.
- Il set di notifiche che escono dal filtro iniziale interrogano il database e determinano se devono essere emesse.
Nel caso in cui la definizione di "azione" si estenda oltre ciò che è convenientemente comprimibile, il passaggio 3 potrebbe essere eseguito alla fine dell'intera esecuzione del programma e tutte le query potrebbero essere registrate - la cui fattibilità è determinabile su un caso-per- caso base.
Il sistema sta per essere completamente implementato per i test nel mio progetto. Tuttavia, sono preoccupato che basarsi esclusivamente su query analizzate sia un'idea piuttosto negativa. In particolare, il filtraggio iniziale presuppone in una certa misura che le query siano prevedibili fino alla specificità delle dipendenze delle notifiche (anche se queste sono solo specifiche fino a che le tabelle sono cambiate, i trigger rappresentano un problema). L'accuratezza del 100% è una priorità assoluta, ma allo stesso tempo anche l'efficienza del sistema è fondamentale, soprattutto se esiste un numero proibitivo di definizioni di notifica.
La mia preoccupazione è ben fondata? Esiste un modo [più] affidabile per ottenere ciò che ho delineato?