Дизайн DAO для доступа к нескольким идентичным базам данных

В настоящее время я занимаюсь разработкой приложения, которое должно получать доступ к нескольким устройствам и собирать различные данные. Данные хранятся в базах данных (одна база данных на устройство), которые полностью идентичны (таблицы, представления, функции, хранимые процедуры и т. д.), несмотря на сами данные. ;) Может быть до 10 устройств, которые могут быть подключены или отключены во время работы.

Теперь вопрос в том, как спроектировать уровень доступа к данным? На данный момент я думаю о двух подходах:

  1. Один DAO на устройство, что приводит к 1..10 экземплярам, ​​каждый из которых содержит информацию о соединении (с сохранением состояния).
  2. A single DAO which accesses all devices by receiving the connection information per method call (stateless).

Приложение должно быть многопоточным (параллельный доступ к базе данных), при этом производительность не критична, а это означает, что некоторые блокировки внутри кода были допустимы. Доступ к устройствам осуществляется только по требованию пользователя. Поскольку я исхожу из жизни RESTful Webservices, в настоящее время я предпочитаю вариант 2, потому что он не имеет состояния.


design-patterns dao data-access-layer multiple-databases
person molehillrocker    schedule 18.09.2014    source источник
comment
Вы пробовали читать о шаблоне проектирования factory?   -  person SSC    schedule 18.09.2014
comment
да. Мой план состоял в том, чтобы реализовать службу необработанных данных (используя SQL и прочее), которая используется одним или несколькими DAO (ами), которые создаются абстрактной фабрикой DAO. Но я не уверен, создавать ли несколько DataServices с отслеживанием состояния или без него.   -  person molehillrocker    schedule 18.09.2014

Ответы (2)


arrow_upward
0
arrow_downward

Первая мысль, которая приходит на ум, — почему бы не хранить все ваши данные в одной базе данных и не создать таблицу «устройства», чтобы различать ваши данные по устройствам? Но это был не ваш вопрос, и я уверен, что у вас есть для этого веская причина.

Лично я бы создал фабрику, которая возвращает правильный DAO на основе «устройства» (идентификатор устройства?). Затем этот DAO должен был бы уже знать информацию о соединении, поэтому я бы сохранил/настроил ее с помощью DAO или внедрил фабрику сеансов для каждой базы данных, если вы используете Hibernate или какой-либо другой ORM.

С решением без сохранения состояния вы просто перемещаете «проблему» хранения информации о соединении/базе данных в другое место. Я думаю, что эта информация концептуально лучше всего подходит для DAO или фабрики сеансов.

person Julius    schedule 18.09.2014
comment
Инструмент предполагается использовать в производственном процессе моего заказчика в качестве некой гарантии качества. Устройства доставляются в испытательную лабораторию, где они должны измерять различные параметры и сохранять результаты в своих базах данных. Чтобы иметь возможность легко сравнивать данные и проверять целостность устройств, приложение извлекает данные, сравнивает и отображает их, поэтому, к сожалению, единая база данных не вариант (сторонние библиотеки тоже -.-) Я думаю, что я пойду с решением с отслеживанием состояния, поскольку перемещение «проблемы» с информацией о соединении вверх еще хуже. :) Спасибо - person molehillrocker; 18.09.2014

arrow_upward
0
arrow_downward

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

Используя один единственный DAO (я предполагаю, что во время выполнения вы будете знать «Тип устройства», для которого необходимо получить данные), вы можете сделать следующее, чтобы выполнить свое требование:

1) Храните сведения о подключении к базе данных в файле свойств.

2) Используйте «Тип устройства», чтобы получить информацию о соединении из файла свойств.

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

person G.S.Tomar    schedule 18.09.2014