Як зменшити тісний зв'язок між двома джерелами даних

У мене виникають проблеми з пошуком правильного рішення наступної проблеми архітектури.

У нашому налаштуванні (накреслено нижче) у нас є 2 джерела даних, де джерело даних A є основним джерелом для елементів типу Foo. Існує вторинне джерело даних, яке може бути використане для отримання додаткової інформації на Foo; однак ця інформація не завжди існує.

Крім того, джерело даних A може використовуватися для отримання елементів типу Bar. Однак кожен бар відноситься до Foo. Складність тут полягає в тому, що кожна смужка повинна посилатися на Foo, який, якщо є, містить також інформацію, доповнену джерелом даних B.

Моє запитання: як зняти щільну зв'язок між SubystemA.1 та DataSourceB?

Я створив додаток з майже такою ж архітектурою даних за ним; у нас є локальна база даних SQL, що містить більшість автоматизованої та внутрішньої повсякденної інформації, а потім сторонній хмарний сервіс, який використовується для продажів, управління обліковими записами, персонал на місцях і т.д. і обладнання, і отримував його з двох різних застосувань, поки я не вступив.

Довго і коротко - це те, що одне джерело даних повинно мати посилання на записи іншого. У нашому випадку, дані сторонніх хмар містять посилання на дані на місці, тому що саме так ми мали контроль. Тепер, маючи ідентифікатор для запису з будь-якого джерела даних, ми можемо отримувати дані з обох; за допомогою ідентифікатора хмари ми витягуємо запис із хмари, отримуємо ідентифікатор на місці та витягуємо дані на місці. За допомогою ідентифікатора на місці ми опитуємо обидва джерела даних на основі цього ідентифікатора.

У моїй системі я не робив жодного об'єкта дочіркою іншого в доменному шарі; будь-яке використання даних із обох магазинів повинно підтримувати два екземпляри об'єкта. Жоден з них не гарантовано існує, тому я зробив це саме так; додаток може працювати лише з хмарними даними, або з даними на місці, або з обома, з більшими обмеженнями, чим меншими є дані.

Однак це не важко змінити, особливо якщо ви впевнені, що одна сторона завжди буде існувати; просто включіть в об’єкт властивість, що представляє сторону, для якої завжди будуть існувати дані, тобто тип об'єкта, що представляє запис іншого сховища даних. Можливе більш вдосконалене "злиття" двох графіків в один.

Цей тип домовленостей обов'язково повинен бути пов'язаний на якомусь рівні. Ви можете мати DAL, який може взаємодіяти з обома сховищами даних, або ви можете сегментувати DAL, по одному на сховище даних, і мати більш високий рівень, такий як контролер, отримувати дані від кожного і з'єднувати їх разом. Але, на певному рівні, у вашій програмі повинні бути розумні, щоб зібрати ці два різних даних джерел даних разом.

Ви можете зменшити з'єднання, необхідне в більшості випадків, абстрагуючи деталі того, звідки беруться дані. Якщо ви отримуєте дані від веб-служби, яка надається вам як екземпляри згенерованих класів, тоді поставте перетворювач, щоб зробити глибоку копію службового класу в те, що ви контролюєте, що не доведеться змінювати, якщо дані джерело робить (тільки якщо схема це робить).

Тепер це може бути величезним починанням; хмара, яку ми використовуємо, має десятки класів доменів, деякі з яких мають сотні полів даних, і - ось кікер - ви дуже легко зможете внести великі зміни в абстрактний тип даних, щоб розмістити перехід на іншу хмару чи інший віддалений джерело даних. З цієї причини я не турбувався; Я використовую згенерований домен веб-сервісу безпосередньо, і тепер, коли відбувається перехід від хмари до зовнішнього (але під нашим контролем) сховища даних, деталі якого я досі не знаю, я просто планую змінити форми та кодові програми програми, де дані "об'єднуються" для відображення нової схеми та / або об'єктів даних. Це велика робота в будь-який спосіб, коли ви її наріжте.

Один із способів вирішити це - зробити агреговане джерело даних, яке містить дані з обох джерел даних в одному місці. Завдання буде періодично запускати для перевірки змін в джерелах Aі B, і запис «дельти» в ваш агрегований джерело даних. Це перетворило б два щільно зв'язаних джерела даних в єдине когерентне джерело даних.

Кілька речей можуть завадити тобі скористатися таким підходом:

• Обсяг даних може бути непомітним - Повна копія Aта її Bпотрібно зробити, подвоївши вимоги до місця.
• Музичні дані будуть живими - пройдуть періоди між часом, коли дані в джерелі змінилися, і завдання, що агрегує, поширить їх у агреговане джерело.
• Вам потрібно узгодити дані з первинними джерелами - Завдання переміщення змін на їх початкові місця стає набагато складнішим, якщо взяти такий підхід.

Здається, що на найвищому рівні є два типи: Foo і Bar, і у вас є лише дві дії верхнього рівня: findFoo(...)і findBar(...). Це інтерфейс до шару вводу / виводу.

Ваше опис джерел даних слід , що існує два способи на А: findFooі findBarта один метод на B: findFooAuxiliaryInformation. У findFooвас буде потрібно злити інформацію з А і В.

Я не впевнений, про яку "тугу муфту" ви маєте на увазі. Є три типи даних , що містяться в цих двох наборів даних: Bar, Foo, і FooAuxData. Зв'язок між Fooі FooAuxDataвластива у вхідних даних, і не може бути зменшена. Але це з'єднання повинно з'являтися лише в findFooметоді. Це найкраще, що ти можеш зробити. Вимога реалізується в одному місці. Якщо він зміниться, вам доведеться змінити цей код.

Ви не можете.

Якщо я правильно розумію, Fooі Barпоходить dsA. Bars належать Foos.
Переважно, ви не хочете, щоб Barідентифікатор був призначений Foos, якщо тільки воно Fooне було доповнене Foo.enhancedInfoцим dsB.

Ваші переваги при призначенні Bars до Foos - це те, що створює вашу щільну з'єднання. Я б визначив це як "виклик вимог", який змушує вас пройти певний шлях.

Таким чином, технічні проблеми полягають у тому, що dsBвони можуть мати або не мати інформацію про будь-яку задану інформацію, Fooяка dsBможе бути навіть недоступною.

Вам потрібно вирішити, наскільки важко і швидко це перевагу Foo.enhancedInfoнасправді. Виходячи з цієї вимоги, ви можете вирішити надати об’єкт Foo+ Bar, чи ні. Якщо дозволити надання не вдосконаленого, Fooлише ускладнює логіку і говорить мені, що уподобання не таке суворе, як може здатися. Визначте , які варіанти Foo, Foo.enhancedі Barваше додаток (s) може підтримувати , і ви будете мати свою остаточну відповідь.

Ви можете зробити інші речі, щоб Fooзблизити відповідну інформацію між собою, і це могло б вирішити деякі з цих проблем. Спосіб фразування вашого запитання здається, що ви вирішили проблему на рівні об'єкта даних, і ви, можливо, не зможете розглянути зміни типу інфраструктури.

Якщо дані у джерелі даних B не можуть стояти самостійно, ви, ймовірно, хочете перенести їх на джерело даних A, якщо це можливо.

Якщо вони незалежні, але пов'язані між собою, вам слід вивчити віртуалізацію даних . Це дозволить програмам обробляти дані як один набір (коли це доречно) агностичним способом. Залежно від вашої платформи, ймовірно, буде існуюча рамка / бібліотека, яка може допомогти вам реалізувати це.