Как проектировать DAO, когда источник данных динамически меняется

Question

Обычно при определении DAO у вас есть установщик для источника данных в объекте DAO.Моя проблема в том, что наш источник данных динамически меняется в зависимости от запроса к серверу.то естькаждый запрос может получить доступ к другому экземпляру базы данных.

Запрос содержит логические свойства, которые позже можно использовать для получения соединения с БД запроса.

Поэтому, когда зависимость внедряет DAO в объект бизнес-логики, мне нужен способ установить свойства DAO во время выполнения (а не во время настройки).

Одним из решений является сохранение источника данных в локальном потоке, но мне не очень нравится возиться с локальными переменными потока.

Другой вариант — иметь метод инициализации для объекта бизнес-логики, который вызывает инициализацию в DAO со свойствами запроса.

Я думаю, это распространенная проблема, можете ли вы предложить общее решение?

Answer 1

Похоже, ваша проблема в том, что вы создаете один экземпляр DAO для своего приложения.Вам либо нужно создать отдельный экземпляр для каждого источника данных (возможно, создать какой-то контроллер dao, чтобы управлять всем этим за вас), либо, возможно, позволить вашим методам в вашем dao быть статическими и передавать всю информацию о том, как подключиться к источнику данных вместе с данные, которые вы сохраняете в каждом методе.

Answer 2

Ваша проблема немного сбивает с толку.Доступ одного DAO к нескольким различным источникам данных может показаться кошмаром для обслуживания.В результате вам следует определить один интерфейс DAO, содержащий все методы, которые вы хотите вызывать.Для каждой базы данных, к которой вы подключаетесь, я бы создал новый класс, реализующий ваш интерфейс DAO.Это позволяет вам иметь несколько реализаций.Затем я бы сохранил эти реализации (каждая из которых имеет свой собственный источник данных) на карте (java.util.Map), используя ваши «логические свойства» в качестве ключа к карте.Поскольку все ваши реализации DAO реализуют ваш интерфейс, вы сможете привязать их к интерфейсу и использовать их взаимозаменяемо.В свой бизнес-объект вы должны внедрить карту реализаций DAO.Надеюсь, это поможет вашему дизайну.

Answer 3

Возможно, вы захотите изучить этот класс:

http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/jdbc/datasource/lookup/AbstractRoutingDataSource.html

Благодаря этому ваши сервисные объекты и объекты доступа к данным будут игнорировать существование какого-либо понятия динамических источников данных.

Обычно вам необходимо реализовать фильтр сервлетов и использовать ThreadLocal, чтобы реализация DataSourceLookup, используемая AbstractRoutingDataSource, могла легко получить доступ к параметрам запроса, которые определяют, какой источник данных будет возвращен.Если вы действительно хотите этого избежать, вы можете реализовать фильтр сервлетов, который устанавливает свойства bean-компонента с областью запроса, и внедрить этот bean-компонент в написанную вами реализацию DataSourceLookup.Компоненты с областью запроса по-прежнему используют ThreadLocal в своей реализации, но, по крайней мере, в этом случае это реализация Spring, а не ваша, и вам не нужно об этом беспокоиться.:)

Похожий подход подробно описан в этой записи блога команды Spring:

http://blog.springsource.com/2007/01/23/dynamic-datasource-routing/

Answer 4

У меня была такая проблема в проекте клиент/сервер.Клиентские и серверные проекты использовали общие интерфейсы Dao.И когда я работал с базой данных, мне приходилось выбирать подходящую реализацию Dao.Мое решение было таким:

IVehicleDao vehicleDao =daoFactory.Get<IVehicleDao>(parameters);
vehicleDao.doSomething();

Получите dao из Factory, передав параметры. Внутри фабрики Dao решите, какую реализацию Dao вернуть.

Answer 5

Я уже сделал это.Вам необходимо создать по одному DAO для каждого класса, и в рамках вашего DAO вам нужно передать DATASOURCE и, наконец, один CONTROLLER класса, где вы выполняете динамический вызов DAO.