2009-02-05 4 views
4

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

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

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

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

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

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

ответ

5

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

+0

Разумный ответ. –

8

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

5

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

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

Get дао от фабрики пропускания parameters.Inside Dao завода решить, какой Dao реализации вернуться ..

6

Вы можете посмотреть в этот класс:

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

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

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

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

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

2

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

Смежные вопросы