Здравствуйте, Lucker, Вы писали:

L>Кто какие способы предпочитает и почему?

наконец-то я понял в чём был твой вопрос ....

если можно, то я задам встречный: а зачем вообще DAO?
манипуляции данными обычно не так тривиальны, чтобы заморачиваться на dao, для простых операций типа получения по id достаточно возможностей, которые даёт hibernate-сессия, для сложных типа запросить сджойненные данные с хитрой фильтрацией — dao не помогает.

я в своих проектах dao не использую, сейчас для одного проекта попросили дописать фичу, я гляжу на тонну кода dao и мне становится плохо

Здравствуйте, C0s, Вы писали:

C0s>наконец-то я понял в чём был твой вопрос ....
C0s>если можно, то я задам встречный: а зачем вообще DAO?

С такими вопросами в архитектуру надо. Обычное такое введение дополнительного слоя. Даже если вроде бы и видимой пользы от него мало, то как минимум читать и разбирать такой код проще.

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, Lucker, Вы писали:

L>>Кто какие способы предпочитает и почему?

C0s>наконец-то я понял в чём был твой вопрос ....

C0s>если можно, то я задам встречный: а зачем вообще DAO?

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

C0s>я в своих проектах dao не использую, сейчас для одного проекта попросили дописать фичу, я гляжу на тонну кода dao и мне становится плохо

Ну если не использовать DAO, то таже тонна кода будет размазана по всей бизнес-логике, только и всего.

Здравствуйте, C0s, Вы писали:

C0s>наконец-то я понял в чём был твой вопрос ....


C0s>если можно, то я задам встречный: а зачем вообще DAO?
"На у как же без кокошника, без кокошника нельзя, а то батюшка вые...т"

C0s>манипуляции данными обычно не так тривиальны, чтобы заморачиваться на dao, для простых операций типа получения по id достаточно возможностей, которые даёт hibernate-сессия, для сложных типа запросить сджойненные данные с хитрой фильтрацией — dao не помогает.

по большому счету у нас есть два типа дао
1) простой. тупо объявлен интерфейс с get/save/dele/find методами. Реализация генерится javassist-ом, на основе GenericDAO реализации + генерятся finder методы, которые тупо вызывают именнованые запросы по имени метода, и передавая туда параметры. Тут можно было бы поизголяться с аннотациями, типа для указания имен запросов, сопоставления параметров и се такое, но простой вариант пока работает.
2) сложные, по сути расширяют простой случай + реализуют сложные запросы через CriteriaAPI.

есть еще plain JDBC DAO для сбора больших объемов статистики (где нужен быстрый нативный доступ к ResulSet)

C0s>я в своих проектах dao не использую, сейчас для одного проекта попросили дописать фичу, я гляжу на тонну кода dao и мне становится плохо
на самом деле кода получается совсем мало, некторые ДАО объявлены только интерфейсно, классы для них генерятся на лету.

Здравствуйте, Trean, Вы писали:

T>Если вдруг захочешь перейти с Hibernate на другую ORM технологию
ИМХО, это миф. Когда соискателей спрашиваешь про MVC они тоже зачастую говорят, чтобы можно было легко разные реализации View использовать. На практике замена таких слоев как View или DAO встречается очень редко.

T>или реализовать отдельные запросы вообще на уровне JDBC без изменения классов бизнес-логики. В этом случае DAO и пригодится, бизнес логика в идеале вообще не должна зависить от деталей реализации механизма сохранения/загрузки данных. Но все имеет свою цену и смотреть надо по ситуации, стоит с DAO заморачиваться или нет.
А вот это уже дело. Такое при использовании ORM сплошь и рядом. Когда в критических местах обнаруживается оверхед из-за специфики ORM, тогда в DAO и дописываются оптимизированые методы.

C0s>>я в своих проектах dao не использую, сейчас для одного проекта попросили дописать фичу, я гляжу на тонну кода dao и мне становится плохо
T>Ну если не использовать DAO, то таже тонна кода будет размазана по всей бизнес-логике, только и всего.
Ну, зачастую и DAO можно реализовать через Ж. Но ведь это никак не говорит о том что от него стоит отказыватся.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Trean, Вы писали:

T>>Если вдруг захочешь перейти с Hibernate на другую ORM технологию
B>ИМХО, это миф. Когда соискателей спрашиваешь про MVC они тоже зачастую говорят, чтобы можно было легко разные реализации View использовать. На практике замена таких слоев как View или DAO встречается очень редко.

Технологии приходят и уходят (Entity Beans), а проекты остаются , всякое бывает (особенно в долгоживущих проектах)

C0s>>>я в своих проектах dao не использую, сейчас для одного проекта попросили дописать фичу, я гляжу на тонну кода dao и мне становится плохо
T>>Ну если не использовать DAO, то таже тонна кода будет размазана по всей бизнес-логике, только и всего.

B>Ну, зачастую и DAO можно реализовать через Ж. Но ведь это никак не говорит о том что от него стоит отказыватся.

Ну и я том же, кстати ни где не встречал статеек вида "DAO pattern considered useless/harmful", только реализация меняется (появление к примеру Generic DAO). Наоборот призывают использовать настоятельно.

Здравствуйте, Trean, Вы писали:

T>Ну если не использовать DAO, то таже тонна кода будет размазана по всей бизнес-логике, только и всего.

предлагаю оттолкнуться от простого, но наиболее часто встречающегося кода (загрузки по id):

1) как это у меня без DAO:

    final SomeObjectInDB o = (SomeObjectInDB) getSession().load(SomeObjectInDB.class, id);

2) как это выглядит с DAO (подсмотрел в проекте, к которому сейчас прикручиваю функциональность):

  final SomeObjectInDB o = SomeObjectInDBDAO.getInstance().get(id);

и там, и там — одна строка. и там, и там, смею утверждать, абсолютно одинаковая понятность (при условии, что читает человек, для которого hibernate-сессия и её API не пустой звук).
спрашивается, зачем городить целый отдельный класс SomeObjectInDBDAO, если наиболее общеупотребительный случай с одинаковым успехом реализуется и без него?!

при этом, специфические запросы, чаще всего, используются в одном месте, т.е. их повторная используемость стремится к нулю. а, скажем, DAO-методы общего назначения типа execQuery(String query) ничего не упрощают

Здравствуйте, Trean, Вы писали:

T>Ну и я том же, кстати ни где не встречал статеек вида "DAO pattern considered useless/harmful", только реализация меняется (появление к примеру Generic DAO). Наоборот призывают использовать настоятельно.

для меня этот уровень выглядит уже неплохо реализованным в виде объекта hibernate-сессии, с помощью которого легко получить доступ к первым объектам, из которых по графу вложенности далее работает уже объекто-ориентированная навигация (геттеры)

Здравствуйте, C0s, Вы писали:

C0s>при этом, специфические запросы, чаще всего, используются в одном месте, т.е. их повторная используемость стремится к нулю. а, скажем, DAO-методы общего назначения типа execQuery(String query) ничего не упрощают
Угу, абсолютно согласен. DAO и DTO — два достаточно бесполезных паттерна, ИМХО. В своих проектах просто использую явный session.get(...), а для повторящихся запросов делаю класс типа <EntityNames>Utils в который добавляю статические методы с кодом запросов.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, C0s, Вы писали:

C0s>>при этом, специфические запросы, чаще всего, используются в одном месте, т.е. их повторная используемость стремится к нулю. а, скажем, DAO-методы общего назначения типа execQuery(String query) ничего не упрощают
C>Угу, абсолютно согласен. DAO и DTO — два достаточно бесполезных паттерна, ИМХО. В своих проектах просто использую явный session.get(...), а для повторящихся запросов делаю класс типа <EntityNames>Utils в который добавляю статические методы с кодом запросов.

Насчет DTO соглашусь, он вообще "вынужденный" шаблон и актуален только для распределенных систем, где необходимо избежать слишком частых вызовов по сети и соответственно больших задержек.
А проблема утилитных статических методов <EntityNames>Utils в усложнении тестируемости (Mock объекты), кроме того если захочется, например в целях оптимизации, подменить реализацию обращения к базе, придется работать с файлами через vcs (ну или коментить в коде), а с DAO достаточно в каком-нибудь spring-conf.xml заменить один бин на другой и вообще не придется трогать код с бизнес-логикой. Такое вот мое имхо.

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, Lucker, Вы писали:

L>>Кто какие способы предпочитает и почему?

C0s>наконец-то я понял в чём был твой вопрос ....

C0s>если можно, то я задам встречный: а зачем вообще DAO?
C0s>манипуляции данными обычно не так тривиальны, чтобы заморачиваться на dao, для простых операций типа получения по id достаточно возможностей, которые даёт hibernate-сессия, для сложных типа запросить сджойненные данные с хитрой фильтрацией — dao не помогает.

C0s>я в своих проектах dao не использую, сейчас для одного проекта попросили дописать фичу, я гляжу на тонну кода dao и мне становится плохо


1. Для удобной замены реального DAO на MockDAO для автомтаических тестов. При условии, что сами DAO продуцируются некой фаббрикой. Тгода просто — для тестов и для реального приложения просто 2 раных конфига...

2. Session managment — важная штука. Как сесию лучше вести? для трэда или для сессии?

Дальше больше... В общем случае, база данных — не единственный storage для данных домена. Например, подсистема классификаторов может быть реализована вообще в виде черного ящика, который вам "корпоративный стандарт" выдал... Но в приложении удобно работать с объектами классификаторов, как с обычными персистентными классами... вот и будут DAO для классификаторов потроха иные иметь.
Или ситуация, когда какие-то сущности "живут" на каком-то удаленном компе с доступом по веб-сервису или еще как. Например, список юзеров в домене... Но удобно было бы "интегрировать" эту сущность в модель домена для единообразности подхода моделирования бизнес-логики... Ну значит будет у вас класс DomainUser и какой-нить DAO к нему, который будет в ActiveDirectory лезть...

ВСе это примеры из реальной жизни.

Ну а вообще, тут дело такое... Если не чувствуете необходимость исопльзования какого-то комопнента сейчас — не используйте. А уж тем более, когда вы скорее бесполезность чувствуете... Нафиг тогда разрывать себя противоречиями?

Здравствуйте, Cyberax, Вы писали:

C>Угу, абсолютно согласен. DAO и DTO — два достаточно бесполезных паттерна, ИМХО. В своих проектах просто использую явный session.get(...), а для повторящихся запросов делаю класс типа <EntityNames>Utils в который добавляю статические методы с кодом запросов.

как ни странно, DTO я не считаю бесполезным. причины этого я как-то уже два-три раза в форуме по java писал

основных, действительно, две:
1) необходимость передачи данных по сети,
2) транзакции — максимально короткие, а данные нужны бывают дольше (пока завершаем обработку запроса), скажем, мне не нравится, если уровень презентации будет неявно обращаться к DB. так вот контейнеры этой информации — очень похожи на DTO, я их у себя обычно так и называю


в остальном же я придерживаюсь схожего подхода (т.е. выделение кода для поддержки только тех запросов, которые повторно используюися, при этом делается это каждый раз наиболее подходящим для конкретного случая способом)

Здравствуйте, noetic, Вы писали:

N>1. Для удобной замены реального DAO на MockDAO для автомтаических тестов. При условии, что сами DAO продуцируются некой фаббрикой. Тгода просто — для тестов и для реального приложения просто 2 раных конфига...

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

N>2. Session managment — важная штука. Как сесию лучше вести? для трэда или для сессии?

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

N>Дальше больше... В общем случае, база данных — не единственный storage для данных домена. Например, подсистема классификаторов может быть реализована вообще в виде черного ящика, который вам "корпоративный стандарт" выдал... Но в приложении удобно работать с объектами классификаторов, как с обычными персистентными классами... вот и будут DAO для классификаторов потроха иные иметь.
N>Или ситуация, когда какие-то сущности "живут" на каком-то удаленном компе с доступом по веб-сервису или еще как. Например, список юзеров в домене... Но удобно было бы "интегрировать" эту сущность в модель домена для единообразности подхода моделирования бизнес-логики... Ну значит будет у вас класс DomainUser и какой-нить DAO к нему, который будет в ActiveDirectory лезть...

в ситуации с разными источниками данных унификация такого рода (когда в тексте программы обращения выглядят одинаковыми) мне кажется вредной, т.к. поощряет программистов-пользователей такого уровня DAO не задумываться, откуда данные. следствием этого будут ошибки, которые исправить будет нелегко.
я предпочитаю, когда вещи называются своими именами, т.е. в конкретном случае часть вызовов будет к сессии hibernate (и тем самым в тексте метода будет явно отражено, какие объекты являются хранимыми в БД), а другая — к web-сервису (и тем самым будет видно, какая информация получается за счёт коммуникации по http).
видеть эту разницу в тексте — фундаментально для адекватной обработки ошибочных и полуошибочных ситуаций и для правильной расстановки вызовов, например, когда часть данных можно получить перед транзакцией БД, тем самым, не удлиняя её.

N>Нафиг тогда разрывать себя противоречиями?

да эта ветка была выделена из обсуждения, у меня-то противоречий нет, просто интересно, откуда у народа появляется желание писать лишний код (лишний код — источник ошибок, а не путь к исправлению имеющихся)

C0s>1) как это у меня без DAO:
C0s>

C0s>    final SomeObjectInDB o = (SomeObjectInDB) getSession().load(SomeObjectInDB.class, id);
C0s>

C0s>2) как это выглядит с DAO (подсмотрел в проекте, к которому сейчас прикручиваю функциональность):
C0s>

C0s>  final SomeObjectInDB o = SomeObjectInDBDAO.getInstance().get(id);
C0s>

C0s>и там, и там — одна строка. и там, и там, смею утверждать, абсолютно одинаковая понятность

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

Здравствуйте, noetic, Вы писали:

N>1. Для удобной замены реального DAO на MockDAO для автомтаических тестов. При условии, что сами DAO продуцируются некой фаббрикой. Тгода просто — для тестов и для реального приложения просто 2 раных конфига...
ИМХО, это абсолютная фантастика. Кроме DAO есть еще взаимодействие с сессией, включая всякие сохранения идентичности объектов и проксиков. Кроме того, объем кода моков для получается просто астрономический — проще использовать базу данных.

В общем, не видел я пока ни одного реального проекта, где было бы тестирование c помощью замены DAO.

N>2. Session managment — важная штука. Как сесию лучше вести? для трэда или для сессии?
А это вообще не забота DAO. По-хорошему, методы DAO типа "loadByPrimaryKey(long key)" в нормальной архитектуре нужно искоренять и заменять на явную передачу сессии в качестве параметра (я у себя так и делаю в статических хэлперах).

N>Или ситуация, когда какие-то сущности "живут" на каком-то удаленном компе с доступом по веб-сервису или еще как. Например, список юзеров в домене... Но удобно было бы "интегрировать" эту сущность в модель домена для единообразности подхода моделирования бизнес-логики... Ну значит будет у вас класс DomainUser и какой-нить DAO к нему, который будет в ActiveDirectory лезть...
А вот так делать точно не надо. AD и web-сервисы часто имеют совершенно отличные от БД характеристики по скорости, взаимодействию с транзакциями и т.п. Лучше такие места отделять явно.

Здравствуйте, C0s, Вы писали:

C0s>как ни странно, DTO я не считаю бесполезным. причины этого я как-то уже два-три раза в форуме по java писал
C0s>основных, действительно, две:
C0s>1) необходимость передачи данных по сети,
C0s>2) транзакции — максимально короткие, а данные нужны бывают дольше (пока завершаем обработку запроса), скажем, мне не нравится, если уровень презентации будет неявно обращаться к DB. так вот контейнеры этой информации — очень похожи на DTO, я их у себя обычно так и называю
Мне в DTO не нравится его параллельность с моделью доменных объектов. Видел несколько проектов, где DTO фактически повторяли модель объектов. Кроме того, появляются проблемы со сложными графами объектов.

Не вижу я особого смысла в DTO, особенно учитывая, что сейчас для persistance'а используют не тяжеловесные entity-бины, а вполне обычные POJO.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Понятность может и одинаковая, а вот как захочется поменять реализацию этого геттера... добавить туда маленький общий фильтрик например...
Фильтрик можно и в Hibernate добавить. Причем он действовать будет на все варианты загрузки, в том числе и через всякие select'ы.

Здравствуйте, Cyberax, Вы писали:

C>Мне в DTO не нравится его параллельность с моделью доменных объектов. Видел несколько проектов, где DTO фактически повторяли модель объектов. Кроме того, появляются проблемы со сложными графами объектов.

я понимаю, у каждого свой опыт у меня DTO не совпадают, в них всегда присутствует интеллектуализм по отношению к некоторым данным, в т.ч. синтетическим,

C>Не вижу я особого смысла в DTO, особенно учитывая, что сейчас для persistance'а используют не тяжеловесные entity-бины, а вполне обычные POJO.

у меня есть явное различие: hibernate-бины — modifable, а DTO — нет, что позволяет писать намного более строгий код, поддающийся верификации на уровне code-review, а не бесконечным ночным автотестированием

Здравствуйте, C0s, Вы писали:

C>>Мне в DTO не нравится его параллельность с моделью доменных объектов. Видел несколько проектов, где DTO фактически повторяли модель объектов. Кроме того, появляются проблемы со сложными графами объектов.
C0s>я понимаю, у каждого свой опыт у меня DTO не совпадают, в них всегда присутствует интеллектуализм по отношению к некоторым данным, в т.ч. синтетическим,
А можно подробнее? Просто интересно, а я расскажу как я организовал распределенную систему из Hibernate'овских бинов.

C>>Не вижу я особого смысла в DTO, особенно учитывая, что сейчас для persistance'а используют не тяжеловесные entity-бины, а вполне обычные POJO.
C0s>у меня есть явное различие: hibernate-бины — modifable, а DTO — нет, что позволяет писать намного более строгий код, поддающийся верификации на уровне code-review, а не бесконечным ночным автотестированием
А кто мешает так же делать с Hibernate'овскими бинами? Выделяешь у них иммутабельный интерфейс и бьешь по пальцам молотком за использование в клиентском коде мутебельных объектов.

Здравствуйте, C0s, Вы писали:

C0s>спрашивается, зачем городить целый отдельный класс SomeObjectInDBDAO, если наиболее общеупотребительный случай с одинаковым успехом реализуется и без него?!
Проблема в том, что при таком подходе весь код оказывается гвоздями прибит к Гибернейту. По сути гибернейт диктует и архитектуру приложения и реализацию и все остальное. Получается уже программирование на гибернейте, а не на языке программирования...
Вынесение же работы с БД в отдельный класс позволяет держать подобный код в резервации, что положительно сказывается на поддержке и понятности.