Като цяло трябва да се избягва прилагането на модел на наблюдател от база данни.
Защо? Той разчита на собствена (нестандартна) технология на доставчика, насърчава риска от блокиране на доставчика на базата данни и поддръжката и причинява малко раздуване. От гледна точка на предприятието, ако не се прави по контролиран начин, може да изглежда като "skunkworks" - внедряване по необичаен начин на поведение, което обикновено се покрива от шаблони и инструменти за приложение и интеграция. Ако се внедри на фино ниво, това може да доведе до тясно свързване с малки промени в данните с огромно количество непредвидена комуникация и обработка, което засяга производителността. Допълнително зъбно колело в машината може да бъде допълнителна точка на прекъсване - може да е чувствително към O/S, мрежа и конфигурация за сигурност или може да има уязвимости в сигурността в технологията на доставчика.
Ако наблюдавате данни за транзакции, управлявани от вашето приложение:
- внедрете модела Observer в приложението си. напр. В Java спецификациите на CDI и javabeans поддържат това директно, а OO персонализираният дизайн според книгата Gang Of Four е перфектно решение.
- по желание изпращайте съобщения до други приложения. Филтри/прехващачи, MDB съобщения, CDI събития и уеб услуги също са полезни за уведомяване.
Ако потребителите директно променят основни данни в базата данни, тогава:
- осигурете отделна администраторска страница в приложението си, за да контролирате опресняването на основните данни ИЛИ
- предоставете отделно приложение за управление на основни данни и изпратете съобщения до зависими приложения ИЛИ
- (най-добрият подход) управлявайте редакциите на основните данни по отношение на качеството (прегледи, тестване и т.н.) и времето (отнасяйте се по същия начин като промяната на кода), популяризиране чрез среди, внедряване и опресняване на данни / рестартиране на приложението към управляван график
Ако наблюдавате транзакционни данни, управлявани от друго приложение (интеграция на споделена база данни) ИЛИ използвате интеграция на ниво данни, като ETL, за да предоставите на приложението си данни:
- опитайте се да имате обекти с данни, написани само от едно приложение (само за четене от други)
- контролна таблица за провеждане на анкета/ETL, за да разберете какви/кога са настъпили промени ИЛИ
- използване на собствено разширение на ниво JDBC/ODBC за уведомяване или запитване, както е добре споменато в отговора на Алекс Пул ИЛИ
- рефакторингът на припокриващи се операции с данни от 2 приложения в споделена SOA услуга може или да избегне изискването за наблюдение, или да го повдигне от операция с данни към SOA/съобщение на по-високо ниво на приложение
- използвайте ESB или адаптер за база данни, за да извикате вашето приложение за известяване или крайна точка на WS за групово прехвърляне на данни (напр. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- избягвайте използването на инфраструктура за разширение на бази данни, като канали или разширени опашки
Ако използвате съобщения (изпращане или получаване), направете го от вашето приложение(а). Съобщенията от DB са малко антипаттерни. В краен случай е възможно да се използват тригери, които извикват уеб услуги (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), но се изисква голямо внимание, за да се направи това по много груб начин, като се извиква бизнес (под)процес, когато набор от данни се промени, вместо да се смазват фини операции от типа CRUD. Най-добре е да задействате задание и то да извика уеб услугата извън транзакцията.
