Я обнаружил, что JPA, или что-то подобное, не поддерживает модель DAO

Question

Я обнаружил, что JPA, или что-то подобное, не поддерживает шаблон DAO. Не знаю, но мне так кажется, особенно с JTA-менеджерами, управляемыми сервером.

После достаточного практического использования шаблона DAO я начал разрабатывать приложение на основе JPA вокруг этого шаблона. Но это не вписывается, ИМО. Я склонен терять довольно характерные черты JPA и все.

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

Другой пример гораздо более тривиален. Предположим, вы запустили запрос, чтобы получить какую-то сущность, которая имеет ленивую загрузку связи один-ко-многим с какой-то другой сущностью. При возврате метода DAO транзакция заканчивается. Ленивая загрузка больше не работает, вы просто получаете null или что-то в этом роде. Чтобы справиться с этим мы загружаем его с нетерпением вручную. мы делаем что-то вроде a.getBList().size().

Таким образом, IMO лучше не делать DAO исключительно, а делать это в своем бизнес-бине, так что вы сможете воспользоваться этими полезными функциями. Или ORM API можно считать самим DAO / Data-слоем. Итак, нам не нужно делать еще один.

Что вы, ребята, думаете об этом?

Примечание: я ни в коем случае не говорю, что шаблон DAO устарел. Действительно, это зависит от случая к случаю.

Answer 1

Для простых приложений я не вижу проблем в использовании EntityManager непосредственно из EJB и пропуска паттерна DAO (я устал от написания слишком большого количества кода). И я действительно чувствую, что именно это поощряют JPA и API Java EE. Но это все еще может быть оправдано для более сложных приложений (для доступа к данным из хранимых процедур, плоских файлов ...). Так что вы правы, это зависит:)

Вы найдете другие просвещенные точки зрения в Убил ли JPA DAO? в InfoQ, но вы не будете удивлены содержанием и заключением, которое можно обобщить так: Для стандартного доступа к данным шаблон DAO больше не нужен, однако он может понадобиться в некоторых более сложных ситуациях, но мы лучше живем без него.

Answer 2

Если вы не определите сам DAO как транзакционный, таких проблем не будет.

Сервисный уровень должен быть транзакционным, потому что транзакция должна охватывать несколько операций. Размещение каждой вставки / обновления в транзакции - не лучший сценарий.

С весной вы достигаете этого очень легко. Без этого вы, возможно, снова включите логику транзакции в свой DAO - то есть dao.beginTransaction() и dao.commitTransaction() и используете ее вместо уровня обслуживания.

Как я понимаю, вы предполагаете, что использование EntityManager непосредственно в классах обслуживания, вероятно, лучше, чем использование класса DAO оболочки. Я не согласен по одной причине. Работая с классом DAO (в лучшем случае с интерфейсом) в ваших классах обслуживания, вы вообще не зависите от API JPA. Вам не нужно создавать Query объекты или тому подобное. Это может не оказаться большим преимуществом, но вы согласитесь, что это лучшая практика. Позже вы можете переключиться на обычный JDBC, обычный текст, XML или любой другой, просто изменив DAO.

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

Итак, в конечном итоге, вернуться к своей точке - это зависит.

Answer 3

DAO используется для проектирования, в то время как JPA является некой «Официальной» оболочкой для функций доступа к данным. Нет никакого способа, которым JPA пытается убить DAO - это может сделать DAO проще в реализации, возможно, настолько простым, что DAO выглядит настолько простым, что его можно игнорировать. Но без уровня DAO преимущества проектирования больше не существует.

Конечно, для «простых» проектов это можно игнорировать. Многие вещи можно «игнорировать», если проект «достаточно прост».