L'implementazione di un modello Observer da un database dovrebbe essere generalmente evitata.
Come mai? Si basa sulla tecnologia proprietaria del fornitore (non standard), promuove il blocco del fornitore di database e supporta il rischio e provoca un po' di rigonfiamento. Dal punto di vista aziendale, se non eseguito in modo controllato, può sembrare "skunkworks" - implementando in modo insolito comportamenti comunemente coperti da modelli e strumenti di applicazione e integrazione. Se implementato a livello di grana fine, può comportare un accoppiamento stretto a minuscole modifiche dei dati con un'enorme quantità di comunicazioni ed elaborazioni impreviste, con ripercussioni sulle prestazioni. Un ingranaggio in più nella macchina può essere un ulteriore punto di rottura:potrebbe essere sensibile al sistema operativo, alla rete e alla configurazione di sicurezza o potrebbero esserci vulnerabilità di sicurezza nella tecnologia del fornitore.
Se stai osservando i dati transazionali gestiti dalla tua app:
- implementa il modello Observer nella tua app. Per esempio. In Java, le specifiche CDI e javabeans lo supportano direttamente e il design personalizzato OO secondo il libro Gang Of Four è una soluzione perfetta.
- facoltativamente invia messaggi ad altre app. Filtri/intercettori, messaggi MDB, eventi CDI e servizi web sono utili anche per la notifica.
Se gli utenti stanno modificando direttamente i dati anagrafici all'interno del database, allora:
- fornire una singola pagina di amministrazione all'interno della tua app per controllare l'aggiornamento dei dati principali OPPURE
- fornire un'app di gestione dei dati master separata e inviare messaggi alle app dipendenti OPPURE
- (approccio migliore) gestire le modifiche ai dati master in termini di qualità (recensioni, test, ecc.) e tempi (considerare come la modifica del codice), promuovere attraverso gli ambienti, distribuire e aggiornare i dati/riavviare l'app in una pianificazione gestita
Se stai osservando i dati transazionali gestiti da un'altra app (integrazione di database condivisi) OPPURE utilizzi l'integrazione a livello di dati come ETL per fornire i dati alla tua applicazione:
- prova ad avere entità dati scritte da una sola app (di sola lettura da altre)
- tabella di controllo di staging/ETL del sondaggio per capire cosa/quando sono state apportate modifiche OPPURE
- utilizzare l'estensione proprietaria a livello di JDBC/ODBC per la notifica o il polling, come indicato nella risposta di Alex Poole OPPURE
- Il refactoring delle operazioni sui dati sovrapposte da 2 app a un servizio SOA condiviso può evitare il requisito di osservazione o spostarlo da un'operazione sui dati a un messaggio SOA/app di livello superiore
- utilizza un ESB o un adattatore di database per richiamare la tua applicazione per la notifica o un endpoint WS per il trasferimento di dati in blocco (ad es. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- evitare l'uso dell'infrastruttura di estensione del database come pipe o accodamento avanzato
Se utilizzi la messaggistica (invia o ricevi), fallo dalle tue applicazioni. La messaggistica dal DB è un po' un antipattern. Come ultima risorsa, è possibile utilizzare trigger che richiamano servizi Web (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), ma è necessaria grande attenzione per eseguire questa operazione in modo molto grossolano, invocando un (sotto)processo aziendale quando un insieme di dati cambia, piuttosto che elaborare operazioni di tipo CRUD a grana fine. È meglio attivare un lavoro e fare in modo che il lavoro chiami il servizio Web al di fuori della transazione.
