Объекты доступа к данным (DAO) - это общий шаблон проектирования, рекомендованный Sun. Но самые ранние примеры Java DAO взаимодействовали напрямую с реляционными базами данных - по сути, они выполняли объектно-реляционное отображение (ORM). В настоящее время я вижу DAO поверх зрелых сред ORM, таких как JDO и Hibernate, и мне интересно, действительно ли это хорошая идея.

Я занимаюсь разработкой веб-службы с использованием JDO в качестве постоянного уровня и обдумываю, стоит ли вводить DAO. Я предвижу проблему при работе с определенным классом, который содержит карту других объектов:

public class Book {
    // Book description in various languages, indexed by ISO language codes
    private Map<String,BookDescription> descriptions;
}

JDO достаточно умен, чтобы сопоставить это с ограничением внешнего ключа между таблицами «BOOKS» и «BOOKDESCRIPTIONS». Он прозрачно загружает объекты BookDescription (я полагаю, что используется ленивая загрузка) и сохраняет их при сохранении объекта Book.

Если бы я должен был ввести «уровень доступа к данным» и написать класс, такой как BookDao, и инкапсулировать весь код JDO в этом, то не будет ли прозрачная загрузка дочерних объектов в JDO обходить уровень доступа к данным? Для согласованности, не должны ли все объекты BookDescription быть загружены и сохранены с помощью какого-либо объекта BookDescriptionDao (или метода BookDao.loadDescription)? Однако рефакторинг таким образом сделает манипулирование моделью излишне сложным.

Итак, мой вопрос: что плохого в том, чтобы вызывать JDO (или Hibernate, или любой другой ORM, который вам нравится) непосредственно на бизнес-уровне? Его синтаксис уже достаточно лаконичен и не зависит от данных. В чем заключается преимущество, если таковое имеется, его инкапсуляции в объектах доступа к данным?