ОРМ и ДАО - вопрос дизайна

Question

В настоящее время я работаю над проектом, к которому пришло это обсуждение, и я хотел спросить других, что они думают об этом.

Шаблон DAO (согласно википедии): "В компьютерном программном обеспечении объект доступа к данным (DAO) - это объект, который обеспечивает абстрактный интерфейс к некоторому типу базы данных или механизму персистентности, предоставляя некоторые конкретные операции без раскрытия деталей базы данных.".

Но, используя ORM, это явно работа ORM (например, Hibernate). Он точно предоставляет абстрактный интерфейс для некоторых (почти любых) типов баз данных.

Рассматривая несколько последних проектов, давайте посмотрим на уровень DAO. Первым шагом всегда является общий hibernate dao с методами save(), findById(), findAll(). Это для меня просто проксирование методов спящего режима.

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

Итак, последний вопрос - вопрос: для такого общего дизайна DAO, что нового приносит шаблон DAO? Если я хочу переключить ядро ​​базы данных, я переключаю его на уровень гибернации. Итак, действительно ли это дает какие-либо преимущества от использования шаблонов DAO в приложениях ORM?

Давайте соберем некоторый опыт:

1. Сколько раз вы видели иерархию классов DAO, тесно связанную с Hibernate (или другим ORM), и что вы думаете об этом?
2. В скольких проектах вы изменили механизм постоянства таким образом, чтобы получать преимущества от уровня DAO (т. Е. Вам нужно было внедрить другой уровень DAO, потому что ваша работа не может быть выполнена на уровне ORM путем переключения диалекта db)?
3. В скольких проектах вы только что разработали большую структуру DAO (интерфейс + класс для каждого объекта домена) и никогда не использовали ее по-настоящему (т.е. вы никогда не меняли реализацию базовой иерархии DAO)?
4. Что вы думаете о приложениях без уровня DAO, просто использующих абстракцию, предоставляемую сеансами ORM?

Пожалуйста, поделитесь с опытом.

Answer 1

ИМХО, шаблон DAO при использовании ORM на самом деле не связан с возможностью переключения ядра базы данных. Это о

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

Я обычно предпочитаю не иметь DAO для объекта домена, а скорее DAO для набора функциональных сценариев использования. Действительно, я обнаружил, что большинство запросов в достаточно сложном приложении связаны не с конкретным доменным объектом, а скорее со сценарием использования или набором вариантов использования. Но YMMV и объединение обоих подходов иногда полезно.

Итак, чтобы ответить на ваши конкретные вопросы:

1. почти всегда. Использование DAO с использованием Hibernate или JPA - это не то же самое, что использование DAO с использованием простого JDBC, в большинстве случаев
2. никогда. Обычно выбор базы данных выполняется задолго до запуска проекта и никогда не меняется.
3. Я склонен разрабатывать DAO только тогда, когда мне это нужно, а не потому, что объект домена существует. Но иметь базовый класс "универсальный DAO" иногда удобно
4. Я думаю, что их сложнее тестировать, они часто плохо структурированы и заканчивают тем, что снова и снова выполняют одни и те же запросы / загрузки, потому что они не изолированы в повторно используемом DAO