Zasadniczo należy unikać implementacji wzorca obserwatora z bazy danych.
Czemu? Opiera się na zastrzeżonej przez dostawcę (niestandardowej) technologii, promuje uzależnienie od dostawcy bazy danych i ryzyko związane z obsługą techniczną oraz powoduje nieco rozdęcia. Z perspektywy przedsiębiorstwa, jeśli nie jest wykonywane w sposób kontrolowany, może wyglądać jak „skunkworks” – implementując w nietypowy sposób zachowanie, które często obejmuje wzorce i narzędzia aplikacyjne i integracyjne. Wdrożenie na poziomie drobnoziarnistym może skutkować ścisłym sprzężeniem z niewielkimi zmianami danych z ogromną ilością nieprzewidywalnej komunikacji i przetwarzania, co ma wpływ na wydajność. Dodatkowa zębatka w maszynie może być dodatkowym punktem krytycznym - może być wrażliwa na konfigurację systemu operacyjnego, sieci i zabezpieczeń lub mogą występować luki w zabezpieczeniach technologii dostawcy.
Jeśli obserwujesz dane transakcyjne zarządzane przez Twoją aplikację:
- zaimplementuj wzorzec obserwatora w swojej aplikacji. Np. W Javie specyfikacje CDI i javabeans obsługują to bezpośrednio, a niestandardowy projekt OO zgodnie z książką Gang Of Four jest idealnym rozwiązaniem.
- opcjonalnie wysyłaj wiadomości do innych aplikacji. Filtry/interceptory, wiadomości MDB, zdarzenia CDI i usługi sieciowe są również przydatne do powiadamiania.
Jeśli użytkownicy bezpośrednio modyfikują dane podstawowe w bazie danych, wówczas:
- udostępnij pojedynczą stronę administratora w swojej aplikacji, aby kontrolować odświeżanie danych podstawowych LUB
- zapewnij oddzielną aplikację do zarządzania danymi głównymi i wysyłaj wiadomości do aplikacji zależnych LUB
- (najlepsze podejście) zarządzaj edycją danych podstawowych pod względem jakości (przeglądy, testowanie itp.) i czasu (traktuj tak samo jak zmiany kodu), promuj w środowiskach, wdrażaj i odświeżaj dane / restartuj aplikację do zarządzanego harmonogramu
Jeśli obserwujesz dane transakcyjne zarządzane przez inną aplikację (integracja ze współużytkowaną bazą danych) LUB używasz integracji na poziomie danych, takiej jak ETL, aby udostępnić dane swojej aplikacji:
- spróbuj mieć jednostki danych pisane przez tylko jedną aplikację (tylko do odczytu przez inne)
- Sonda staging/tabela kontrolna ETL, aby zrozumieć, co/kiedy nastąpiły zmiany LUB
- użyj zastrzeżonego rozszerzenia na poziomie JDBC/ODBC do powiadamiania lub odpytywania, jak wspomniano w odpowiedzi Alexa Poole'a LUB
- Refaktoryzacja nakładających się operacji na danych z 2 aplikacji do udostępnionej usługi SOA może albo uniknąć wymogu obserwacji, albo przenieść ją z operacji na danych do komunikatu wyższego poziomu SOA/aplikacji
- użyj ESB lub adaptera bazy danych, aby wywołać aplikację w celu powiadomienia lub punktu końcowego WS do zbiorczego przesyłania danych (np. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- unikaj korzystania z infrastruktury rozszerzenia bazy danych, takiej jak potoki lub zaawansowane kolejkowanie
Jeśli korzystasz z wiadomości (wysyłaj lub odbieraj), rób to w swojej aplikacji. Wysyłanie wiadomości z DB to trochę antywzorzec. W ostateczności można użyć wyzwalaczy, które wywołują usługi sieciowe (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), ale wymagana jest duża ostrożność, aby zrobić to w bardzo zgrubny sposób, wywołując (pod) proces biznesowy, gdy zestaw danych ulegnie zmianie, zamiast przetwarzać drobnoziarniste operacje typu CRUD. Najlepiej uruchomić zadanie i poprosić, aby zadanie wywołało usługę sieciową poza transakcją.
