Het implementeren van een Observer-patroon uit een database moet over het algemeen worden vermeden.
Waarom? Het is gebaseerd op door de leverancier gepatenteerde (niet-standaard) technologie, bevordert de lock-in van databaseleveranciers en ondersteunt risico's, en veroorzaakt een beetje opgeblazen gevoel. Vanuit een bedrijfsperspectief kan het, als het niet op een gecontroleerde manier wordt gedaan, eruitzien als "skunkworks" - het implementeren van op een ongebruikelijke manier gedrag dat gewoonlijk wordt gedekt door toepassings- en integratiepatronen en -tools. Als het op een fijnkorrelig niveau wordt geïmplementeerd, kan het leiden tot een nauwe koppeling met kleine gegevenswijzigingen met een enorme hoeveelheid onvoorspelbare communicatie en verwerking, wat de prestaties beïnvloedt. Een extra tandwiel in de machine kan een extra breekpunt zijn - het kan gevoelig zijn voor besturingssysteem, netwerk en beveiligingsconfiguratie of er kunnen beveiligingsproblemen zijn in de technologie van leveranciers.
Als u transactiegegevens bekijkt die door uw app worden beheerd:
- implementeer het Observer-patroon in uw app. bijv. In Java ondersteunen CDI en Javabeans dit direct, en OO custom design volgens Gang Of Four boek is een perfecte oplossing.
- stuur optioneel berichten naar andere apps. Filters/interceptors, MDB-berichten, CDI-gebeurtenissen en webservices zijn ook handig voor meldingen.
Als gebruikers stamgegevens rechtstreeks wijzigen in de database, dan:
- een enkele beheerderspagina in uw app bieden om het vernieuwen van mastergegevens te beheren OF
- een aparte app voor masterdatabeheer bieden en berichten verzenden naar afhankelijke apps OF
- (beste aanpak) beheer mastergegevensbewerkingen in termen van kwaliteit (beoordelingen, testen, enz.) en timing (behandel hetzelfde als codewijziging), promoot via omgevingen, implementeer en ververs gegevens / herstart app naar een beheerde planning
Als u transactiegegevens observeert die worden beheerd door een andere app (integratie van gedeelde databases) OF u gebruikt integratie op gegevensniveau zoals ETL om uw toepassing van gegevens te voorzien:
- probeer gegevensentiteiten door slechts één app te laten schrijven (alleen-lezen door anderen)
- poll-staging/ETL-controletabel om te begrijpen wat/wanneer er wijzigingen zijn opgetreden OF
- gebruik JDBC/ODBC-niveau propriëtaire extensie voor notificatie of polling, zoals ook vermeld in het antwoord van Alex Poole OF
- overlappende gegevensbewerkingen van twee apps omzetten in een gedeelde SOA-service kan de observatievereiste vermijden of deze van een gegevensbewerking naar een hoger SOA/app-bericht opheffen
- gebruik een ESB of een databaseadapter om uw toepassing aan te roepen voor melding of een WS-eindpunt voor bulkgegevensoverdracht (bijv. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- vermijd het gebruik van database-uitbreidingsinfrastructuur zoals leidingen of geavanceerde wachtrijen
Als u gebruik maakt van messaging (verzenden of ontvangen), doe dit dan vanuit uw applicatie(s). Berichten vanuit de database zijn een beetje een antipatroon. Als laatste redmiddel is het mogelijk om triggers te gebruiken die webservices aanroepen (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), maar er is grote zorgvuldigheid vereist om dit op een zeer grove manier te doen, waarbij een zakelijk (sub)proces wordt aangeroepen wanneer een reeks gegevens verandert, in plaats van fijnkorrelige bewerkingen van het CRUD-type te kraken. U kunt het beste een taak activeren en de taak de webservice laten bellen buiten de transactie om.