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

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