Я немного знаю этот подход, но мне трудно в это поверить. Мои приложения обычно получают данные из БД, обрабатывают их и снова помещают в БД. Тогда для меня это намного ближе к реальной ситуации, проверить это на БД (и, кстати, проверить вещи, связанные с постоянством, такие как отношения и т. Д.). Извините за мой нонконформизм, недавно у меня на столе было два проекта среднего размера, написанных с использованием совершенно другого подхода, и я вижу там, что приложение classis имеет код на 100-150% больше (и требуется рабочее время), совершенно без какой-либо причины - это заставило меня задуматься об этом;)
тоящее время я работаю над проектом, к которому пришло это обсуждение, и я хотел спросить других, что они думают об этом.
Шаблон DAO (согласно википедии): «В компьютерном программном обеспечении объект доступа к данным (DAO) - это объект, который обеспечивает абстрактный интерфейс к некоторому типу базы данных или механизм персистентности, предоставляя некоторые специфические операции без раскрытия деталей базы данных. ».
Но, используя ORM, это явно работа ORM (например, Hibernate). Он точно предоставляет абстрактный интерфейс для некоторых (почти любых) типов баз данных.
Рассматривая несколько последних проектов, давайте посмотрим на слой DAO. Первым шагом всегда является общий hibernate dao с методами save (), findById (), findAll (). Это для меня просто проксирование методов спящего режима.
На шаг вперед я вижу такие интерфейсы, как предложено здесьОбщий шаблон DAO в Hibernateто, что полностью связывает DAO с гибернацией для сохранения (слияние, критерии запроса). Этот DAO не будет использоваться с другим механизмом персистентности, кроме Hibernate.
Итак, последний вопрос - вопрос: для такого общего дизайна DAO, что нового приносит шаблон DAO? Если я хочу переключить ядро базы данных, я переключаю его на уровень гибернации. Итак, действительно ли это дает какие-либо преимущества от использования шаблонов DAO в приложениях ORM?
Давайте соберем некоторый опыт:
Сколько раз вы видели иерархию классов DAO, тесно связанную с Hibernate (или другим ORM), и что вы думаете об этом?В скольких проектах вы изменили механизм постоянства таким образом, чтобы получать преимущества от уровня DAO (т. Е. Вам нужно было реализовать другой уровень DAO, потому что ваша работа не может быть выполнена на уровне ORM путем переключения диалекта db)?В скольких проектах вы только что разработали большую структуру DAO (интерфейс + класс для каждого объекта домена) и никогда не использовали ее по-настоящему (т.е. вы никогда не меняли реализацию базовой иерархии DAO)?Что вы думаете о приложениях без уровня DAO, просто использующих абстракцию, предоставляемую сеансами ORM?Пожалуйста, поделитесь с опытом.