Лучший подход к архитектуре интеграции двух отдельных баз данных?

Question

Я столкнулся со следующими вопросами на работе, и у меня нет опыта или знаний, чтобы ответить на них, я надеюсь, что некоторые из вас, более мудрые люди, смогут указать мне правильное направление , любые ответы будут с благодарностью!

Сценарий

У нас есть два аспекта бизнеса, использующих отдельные базы данных: человеческие ресурсы и операционные зоны (уход на дому).
Отдел кадров отслеживает сотрудников компании, схемы смен, отсутствие, оплату и т. Д. Служба Homecare отслеживает информацию о клиентах, посещения на дому, даты посещений и сотрудников, ответственных за обеспечение этого посещения.

Эти две системы являются отдельными, и в настоящее время мы находимся в процессе поиска способов их интеграции.

Кроме того, мы смотрим, как организовать наш код, который просматривает эти две базы данных, в многократно используемые организованные библиотеки.

У нас есть три приложения, повторно использующие HumanResources.dll, отвечающие за связь с контекстом объекта EF 4, который содержится в библиотеке. Контекст объекта - это почти зеркальное отображение базы данных в ее нынешнем виде.

Вопросы

---

Мы собираемся добавить четвертое приложение, которое будет использовать данные в базе данных HR.

Делаем ли мы:

Создать новую модель данных EF, ответственность за предоставление информации что нужно только приложению, а дублируя некоторые общие объекты, такие как в качестве сотрудника.

ИЛИ

Добавить новые сущности / таблицы в уже большая модель и принять ее собирается стать большим.

---

В более долгосрочной перспективе нам необходимо объединить информацию о шаблоне смены в базе данных HR с данными о посещениях клиентов в базе данных по операционным районам (Homecare) в 5-м приложении. У нас есть представление о том, что мы можем сделать; мы придумали следующее:

Создайте слой, который находится между Контекст объекта HumanResources и Контекст объекта на дому, ответственный для объединения двух наборов данных вместе.

Существуют ли другие подходы, которые могли бы принести нам пользу?

Answer 1

Реализация шаблона фасада

Фасад - это в основном адаптер для сложной подсистемы.Поскольку у вас есть две подсистемы, я бы рекомендовал создать три класса со следующими функциональными возможностями:

1. HumanResourcesFacade: класс, охватывающий все функциональные возможности "Человеческие ресурсы".Задача этого класса состоит в том, чтобы представить методы, которые выполняют каждую единицу работы, за которую отвечает приложение Human Resources, без предоставления клиенту какой-либо информации о приложении Human Resources.

2. HomecareFacade: Класс, охватывающий все функции "Уход на дому".Задача этого класса - раскрыть методы, выполняющие каждую единицу работы, за которую отвечает приложение Homecare, без предоставления клиенту какой-либо информации о базе данных Homecare.

3. ApplicationFacade: Класс, который охватывает как HumanResourcesFacade, так и HomecareFacade и предоставляет вашим клиентам открытые методы, которые не требуют знания внутренней работы любого из двух вложенных фасадов.Задача этого класса состоит в том, чтобы знать: (a) какой из двух вложенных фасадов отвечает за каждый клиентский вызов, (b) выполнить клиентский вызов ApplicationFacade, выполнив вызов соответствующего метода на вложенном Facade, и (c) перевод данных, полученных от вложенного фасада, в формат, который может использоваться клиентом и не зависит от форматов данных любого из вложенных фасадов.

Я бы рекомендовал использовать объектную модель POCO для создания общего представления данных в коде, которое не зависит от фактической реализации постоянства.Техника доменной модели, предложенная Адрианом К., является хорошим подходом, но если вы не знакомы с шаблонами и методологией, это может привести к путанице и занять намного больше времени, чем методы, которые более интуитивны.Альтернативой является просто использование объектов данных и Data Mapper .Картограф данных, в основном, берет данные из источника данных и превращает их в объект, который не зависит от источника данных или объекта картографа.Я включил ссылку ниже.

Одна вещь, которую я хотел бы уточнить, состоит в том, что, хотя я сказал, что у ApplicationFacade есть три задания, я не советую вам нарушать Принцип единой ответственности .Я не имею в виду, что класс должен сам выполнять все эти три вещи, но он должен заключать в себе тот механизм, который вы решите использовать для выполнения этого процесса, и что никакие другие части приложения не должны получать доступ к этим проблемам извне ApplicationFacade.Например, ваши бизнес-объекты не должны знать, из какого источника данных они были созданы, - эта информация не должна быть доступна ни из чего, кроме того, что инкапсулировано классом ApplicationFacade.

Справочные статьи

• Мартин Фаулер о фасадах приложений
• Мартин Фаулер о преобразователях данных
• Бесплатное, но подробное введение в домен, управляемыйДизайн

Answer 2

Похоже, вам нужно серьезно заняться моделированием данных.

Тебе определенно это нужно на длительный срок, чтобы не втянуть себя в серьезную ссору. (если есть одна вещь, которая существенно повлияет на вашу способность поддерживать / расширять системы и поддерживать рост бизнеса - это управление данными). Хорошая вещь о (бизнес) данных заключается в том, что ваши бизнес-заинтересованные стороны будут (или должны) хорошо понимать их и иметь соответствующую мотивацию для поддержки вас. Ценность, которую принесет такое упражнение, должна быть легкой продажей. Помочь в этом в краткосрочной перспективе тоже поможет.

Источники данных, которые поставляются с пакетами продуктов (Commercial Off The Shelf - COTS), не будут открыты для изменений без риска для этих систем - но это не значит, что вы не можете использовать ETL и другие базы данных для создания витрин данных которые объединяют разрозненные данные. При таком подходе важное значение будет иметь моделирование данных и отображение данных между системами, а также время.

У вас будет больше гибкости с собственными приложениями - но вы, возможно, захотите противостоять тактическим изменениям, если у вас нет веских причин, в противном случае вам, вероятно, придется все равно их переделать.

В рамках этого упражнения вы захотите рассмотреть Система записи каждого фрагмента данных - откуда она взялась? Кому это принадлежит? Вы можете начать с высокого уровня, составив концептуальную модель данных, которая, вероятно, будет иметь дело больше с логическими наборами данных, чем с конкретными «столбцами».

Используйте эту информацию для принятия дальнейших решений.

С точки зрения вашего непосредственного подхода (и вашего вопроса): в общих чертах он подумал бы о том, чтобы поместить слой абстракции между вашими системами и данными, чтобы приложения были защищены от изменений, когда это произойдет.

Создайте новую модель данных EF, отвечающую за предоставление информации, которая нужна только приложению, при дублировании некоторых общих сущностей, таких как Сотрудник.

Большая проблема с дублированием состоит в том, чтобы привести данные в грязное состояние - что является "реальной" записью. Это может легко убить тебя. Каковы преимущества этого подхода в вашем контексте? Будете ли вы делать это с точки зрения поддержки? Легкость развития?

Answer 3

Это очень сильно зависит от того, что вы подразумеваете под интеграцией.

• Если вы просто хотите объединить различные таблицы для целей отчетности, вам следует рассмотреть некоторый процесс извлечения и загрузки выбранных данных из каждогоСистема в хранилище данных.Вам нужно будет определить общую модель данных для обеих систем.Затем эти данные можно использовать для составления отчетов.
• Если вы хотите, чтобы одна система вызывала службы или извлекала данные из другой системы, я бы порекомендовал вам использовать классический шаблон SOA.Предоставьте доступ к функциям, которые вы хотите сделать доступными для другой системы, в виде сервисов через сообщения SOAP, REST или аналогичные.И заставьте клиентские системы использовать эти методы и только эти методы для отправки или извлечения данных.

Избегайте, если вообще возможно, заглядывать непосредственно в базу данных сторонних систем, реплицируя данные из одной системы в другую,или делать прямые вызовы API к исходной системе.Руководящим принципом должно быть «если я заменю систему X системой SuperX, насколько легко будет поддерживать работу других систем».

Answer 4

Поскольку вы ищете долгосрочное решение и оно касается инфраструктуры бизнеса, я рекомендую вам перейти на LDAP . Прочитайте.