L'implémentation d'un pattern Observer à partir d'une base de données doit généralement être évitée.
Pourquoi? Il s'appuie sur une technologie propriétaire (non standard) du fournisseur, favorise le verrouillage du fournisseur de base de données et le risque de prise en charge, et provoque un peu de gonflement. Du point de vue de l'entreprise, si cela n'est pas fait de manière contrôlée, cela peut ressembler à "skunkworks" - implémentant de manière inhabituelle un comportement généralement couvert par les modèles et outils d'application et d'intégration. S'il est mis en œuvre à un niveau fin, il peut entraîner un couplage étroit avec de minuscules modifications de données avec une énorme quantité de communications et de traitements imprévus, affectant les performances. Un rouage supplémentaire dans la machine peut être un point de rupture supplémentaire - il peut être sensible à la configuration du système d'exploitation, du réseau et de la sécurité ou il peut y avoir des failles de sécurité dans la technologie du fournisseur.
Si vous observez des données transactionnelles gérées par votre application :
- implémentez le modèle Observer dans votre application. Par exemple. En Java, les spécifications CDI et javabeans prennent en charge cela directement, et la conception personnalisée OO selon le livre Gang Of Four est une solution parfaite.
- envoyer éventuellement des messages à d'autres applications. Les filtres/intercepteurs, les messages MDB, les événements CDI et les services Web sont également utiles pour la notification.
Si les utilisateurs modifient directement les données de base dans la base de données, alors soit :
- fournir une page d'administration unique dans votre application pour contrôler l'actualisation des données de base OU
- fournir une application de gestion des données de base distincte et envoyer des messages aux applications dépendantes OU
- (meilleure approche) gérer les modifications des données de base en termes de qualité (révisions, tests, etc.) et de calendrier (traiter comme un changement de code), promouvoir via les environnements, déployer et actualiser les données/redémarrer l'application selon un calendrier géré
Si vous observez des données transactionnelles gérées par une autre application (intégration de base de données partagée) OU si vous utilisez une intégration au niveau des données telle qu'ETL pour fournir des données à votre application :
- essayez d'avoir des entités de données écrites par une seule application (en lecture seule par d'autres)
- Interroger la mise en scène du sondage/la table de contrôle ETL pour comprendre quoi/quand les changements se sont produits OU
- utiliser l'extension propriétaire de niveau JDBC/ODBC pour la notification ou l'interrogation, comme indiqué dans la réponse d'Alex Poole OU
- refactoriser les opérations de données qui se chevauchent à partir de 2 applications dans un service SOA partagé peut soit éviter l'exigence d'observation, soit la faire passer d'une opération de données à un message SOA/application de niveau supérieur
- utiliser un ESB ou un adaptateur de base de données pour appeler votre application pour la notification ou un point de terminaison WS pour le transfert de données en masse (par exemple, Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- évitez d'utiliser l'infrastructure d'extension de base de données telle que les canaux ou la mise en file d'attente avancée
Si vous utilisez la messagerie (envoi ou réception), faites-le depuis votre/vos application(s). La messagerie de la base de données est un peu un anti-modèle. En dernier recours, il est possible d'utiliser des déclencheurs qui invoquent des services Web (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), mais il faut faire très attention pour le faire de manière très grossière, en invoquant un (sous-)processus métier lorsqu'un ensemble de données change, plutôt que d'effectuer des opérations de type CRUD à grain fin. Il est préférable de déclencher une tâche et que la tâche appelle le service Web en dehors de la transaction.
