Объекты доступа к данным (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 descriptions;
}

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

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

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