Я обнаружил, что JPA, или что-то подобное, не поддерживает модель DAO
Я обнаружил, что JPA, или что-то подобное, не поддерживает модель DAO. Не знаю, но мне так кажется, особенно с JTA-менеджерами, управляемыми сервером.
После адекватного практического использования шаблона DAO я начал разрабатывать приложение на основе JPA вокруг этого шаблона. Но это не вписывается, ИМО. Я склонен терять довольно характерные черты JPA и все.
Хорошо, предположим, что вы запустили запрос с пессимистической блокировкой, и он возвратил список объектов из метода DAO. По возвращении транзакция заканчивается и блокировка исчезает (случай с JTA-менеджером, управляемым сервером). Так что, нет смысла, грубо говоря. Впрочем, есть веские случаи.
Другой пример гораздо более тривиален. Предположим, вы запускаете запрос, чтобы получить какую-то сущность, которая имеет ленивую загрузку связи один-ко-многим с какой-то другой сущностью. При возврате метода DAO транзакция заканчивается. Ленивая загрузка больше не будет работать, вы просто получите null или что-то. Чтобы справиться с этим, мы загружаем его с нетерпением вручную. мы делаем что-то вроде a.getBList().size(),
Таким образом, IMO лучше не создавать DAO исключительно и делать это в своем бизнес-компоненте, чтобы вы могли воспользоваться этими полезными функциями. Или ORM API можно считать самим DAO/Data-слоем, возможно. Итак, нам не нужно делать другое.
Что вы, ребята, думаете об этом?
Примечание. Я ни в коем случае не говорю, что шаблон DAO устарел. Действительно, это зависит от случая к случаю.
3 ответа
Для простых приложений я не вижу проблем в использовании EntityManager непосредственно из EJB-компонентов и пропуска паттерна DAO (я устал писать слишком много кода). И я действительно чувствую, что именно это поощряют JPA и API Java EE. Но это все еще может быть оправдано для более сложных приложений (для доступа к данным из хранимых процедур, плоских файлов...). Так что вы правы, это зависит:)
Вы найдете некоторые другие просвещенные точки зрения в " Убил ли JPA DAO?" в InfoQ, но вы не будете удивлены содержанием и выводом, который можно резюмировать следующим образом: вам больше не нужен шаблон DAO для стандартного доступа к данным, однако он может вам понадобиться в некоторых более сложных ситуациях, но мы живем лучше без него
Если вы не определите сам DAO как транзакционный, таких проблем не будет.
Сервисный уровень должен быть транзакционным, потому что транзакция должна охватывать несколько операций. Помещение каждой вставки / обновления в транзакцию - не лучший сценарий.
С весной вы достигаете этого очень легко. Без этого вы, возможно, снова включите логику транзакции в свой DAO - т.е. dao.beginTransaction() а также dao.commitTransaction() и использовать это из сервисного уровня вместо этого.
Как я понимаю, вы предлагаете использовать EntityManager прямо в классах обслуживания, вероятно, лучше, чем иметь обертку DAO учебный класс. Я не согласен по одной причине. Работая с классом DAO (в лучшем случае с интерфейсом) в ваших классах обслуживания, вы вообще не зависите от API JPA. Вам не нужно строить Query объекты или лайки. Это может не оказаться большим преимуществом, но вы согласитесь, что это лучшая практика. Позже вы можете переключиться на обычный JDBC, обычный текст, XML или любой другой, просто изменив DAO.
Хотя это широко используется в качестве примера того, почему вы должны абстрагировать что-то в другом слое, чаще всего это просто чрезмерный дизайн. Но иногда тот факт, что все ваши операции доступа к базе данных выполняются в одном месте, означает, что вы можете добавить ведение журнала, проверки уровня доступа и т. Д. (Да, иногда DAO не особенно подходит для этого).
Итак, в конечном итоге, вернуться к своей точке - это зависит.
DAO используется для проектирования, в то время как JPA является "Официальной" оболочкой для функций доступа к данным. Нет никакого способа, которым JPA пытается убить DAO - это может сделать DAO проще в реализации, возможно, настолько простым, что DAO выглядит настолько простым, что его можно игнорировать. Но без уровня DAO преимущества дизайна больше не существует.
Конечно, для "простых" проектов это можно игнорировать. Многие вещи можно "игнорировать", если проект достаточно "прост".