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