Лучшая практика для шаблона ДАО?
Я видел, что много кодов использует шаблон сервисного дао, я не знаю источник этого шаблона. Это вызывает переднее обслуживание вызовов слоя, затем делегирует часть сервисной задачи к дао.
Я хочу спросить:
- Уровень DAO делает чисто связанную с доступом к данным задачу? Что относительно вещей как инкапсуляция исключения?
- Есть ли какой-либо другой шаблон, может использоваться для замены этого или лучше, чем это?
- Я думаю, pojo модели предметной области и сценарии транзакции делают даже простую проблему, стал сложным, действительно ли возможно полностью устранить слой дао?
2 ответа
В идеале, ваш уровень DAO «абстрагирует» доступ к какой-либо системе хранения данных (базе данных, файловой системе, каталогу LDAP, ...). В этом смысле он используется только для задач, связанных с доступом к данным. Однако у вас также может быть слой DAO, который обращается к веб-сервису или какому-либо другому компоненту, внешнему по отношению к вашему приложению. Это ключевой момент, он предоставляет доступ к какому-то внешнему компоненту.
Основная идея заключается в том, что нет деталей реализации вашего уровня DAO, которые уходят на более высокие уровни (изоляция). Хорошая отправная точка для размышлений об этом: что мне нужно делать, если я планирую заменить компонент (например, базу данных), к которому мой уровень DAO предоставляет доступ? Например, у вас есть данные в файлах XML, и вы планируете перенести их в базу данных.
Предположим, у вас есть все виды исключений, связанных с XML, которые выходят за пределы вашего уровня DAO. Тогда становится довольно сложно перенести уровень XML на уровень базы данных. Однако, если вы инкапсулировали все детали реализации вашего уровня DAO, это станет намного проще.
В конце концов, речь идет о ремонтопригодности вашего кода. Чем меньше у вас зависимости от деталей реализации определенного уровня (сервисы, DAO, ...), тем лучше будет ваш код поддерживать.
Основная цель такого уровня - обеспечить абстракцию серверной части устойчивости. однако в большинстве случаев из-за специфики серверной части персистентности полное скрытие невозможно; Типичный пример - обработка запросов.Чтобы запросить БД с помощью спящего режима, вы напишете какой-то код запроса (с использованием HQL, API запросов, ...) и совершенно другую парадигму при использовании JCR, BigTable или чего-то еще. Как следствие, в большинстве случаев этот шаблон не работает.
Кроме того, существует еще более раздражающая проблема DAO / DTO. Затем вас подталкивают к написанию первого класса, содержащего ваши данные, а затем второго копирования данных из вашего первого без какой-либо дополнительной ценности просто ради изоляции слоев.
Однако в этой области была проделана определенная работа. Для микро-фреймворка, который я начал и реализовал для google-app-engine, я составил небольшой список так называемых dao-фреймворков, упрощающих этот довольно приземленный код.
Обратите внимание, что в будущем я планирую обеспечить полную прозрачность с помощью определения службы gaedo, но это только надежда ;-) (и, я думаю, это не представляет для вас непосредственного интереса).