Лучшая практика для модели DAO?

Question

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

Я хочу спросить:

1. Уровень DAO выполняет только задачу, связанную с доступом к данным? Как насчет таких вещей, как инкапсуляция исключений?
2. Можно ли использовать какой-либо другой шаблон для замены этого или лучше этого?
3. Я думаю, что модели домена pojo и сценарии транзакций делают даже простую задачу сложной, возможно ли полностью устранить слой дао?

Answer 1

В идеале, ваш уровень DAO «абстрагирует» доступ к некоторой системе хранения данных (база данных, файловая система, каталог LDAP, ...). Таким образом, в этом смысле он используется только для задач, связанных с доступом к данным. Однако у вас также может быть слой DAO, который обращается к веб-службе или к другому компоненту, внешнему по отношению к вашему приложению. Это ключевой момент, он обеспечивает доступ к некоторому внешнему компоненту.

Основная идея заключается в том, что нет деталей реализации вашего уровня DAO, которые бы выходили на более высокие уровни (изоляция). Хорошая отправная точка для размышления об этом: что мне нужно сделать, если я планирую заменить компонент (например, базу данных), к которому мой уровень DAO предоставляет доступ? Например, у вас есть некоторые данные в файлах XML, и вы планируете перенести данные в базу данных.

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

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

Answer 2

Основная цель такого уровня - обеспечить абстракцию бэкэнда персистентности. однако в большинстве случаев из-за специфики персистентного бэкэнда полное скрытие невозможно; Типичным примером является обработка запросов. Чтобы выполнить запрос к БД с помощью hibernate, вы напишите некоторый код запроса (с использованием HQL, API запросов, ...) и совершенно другую парадигму при использовании JCR, BigTable или чего-то еще. Как следствие, в большинстве случаев этот шаблон не работает.

Кроме того, есть еще более раздражающая проблема DAO / DTO. Затем вас подталкивают к написанию первого класса, содержащего ваши данные, затем второго копирования данных из вашего первого без какого-либо дополнительного значения только для изоляции слоя.

Однако в этой области была проделана определенная работа. Для микро-фреймворка, который я начал и реализовал для google-app-engine, я составил маленький список так называемых dao-фреймворков, упрощающих этот довольно приземленный код.

Обратите внимание, что в будущем я планирую обеспечить полную прозрачность благодаря определению сервиса gaedo, но это всего лишь надежда ;-) (и я полагаю, что он не представляет непосредственного интереса для вас).

Answer 3

Доступ к данным зависит от источника данных. Доступ к постоянному хранилищу, например к базе данных, сильно различается в зависимости от типа хранилища (реляционные базы данных, объектно-ориентированные базы данных, плоские файлы и т. Д.) И реализации поставщика.

Использование объекта доступа к данным (DAO) для абстрагирования и инкапсуляции всего доступа к источнику данных. DAO управляет соединением с источником данных для получения и хранения данных.

DAO реализует механизм доступа, необходимый для работы с источником данных. Источником данных может быть постоянное хранилище, такое как СУБД, внешняя служба, такая как биржа B2B, хранилище, такое как база данных LDAP, или бизнес-служба, доступ к которой осуществляется через протокол CORBA Internet Inter-ORB Protocol (IIOP) или низкоуровневые сокеты. Бизнес-компонент, основанный на DAO, использует более простой интерфейс, предоставляемый DAO для своих клиентов. DAO полностью скрывает детали реализации источника данных от своих клиентов. Поскольку интерфейс, предоставляемый DAO клиентам, не изменяется при изменении реализации базового источника данных, этот шаблон позволяет DAO адаптироваться к различным схемам хранения, не затрагивая своих клиентов или бизнес-компоненты. По сути, DAO действует как адаптер между компонентом и источником данных.