По мотивам этой темы :

mad_nazgulHibernate решает сложные проблемы, которые сам себе в начале создал.
Из-за отображения ООМ на РМД.
Простые вещи он усложняет до невозможности.
Вместо, того, чтобы делать нормальный DTO ручками.
Приходиться скрещивать ужа с ежом, чтобы получить пони.
<:o)
Stanislav Bashkyrtsevmad_nazgulHibernate решает сложные проблемы, которые сам себе в начале создал.
Сложные проблемы которые он решает и которые сам себе не создавал - это ленивая загрузка и поддержка больших графов объектов, dirty check'и, каскады, поддержание PersistenceContext'a и т.п.
mad_nazgulПростые вещи он усложняет до невозможности.
Вместо, того, чтобы делать нормальный DTO ручками.
Приходиться скрещивать ужа с ежом, чтобы получить пони.Простые штуки вроде вернуть DTO можно сделать как с Hibernate'ом:
- с помощью select new
- создание более удобных сущностей под задачу, которые мапятся на те же таблицы, но по-другому
- маппинг на вьюшки

Так можно решать их и без него, никто не мешает миксовать Hibernate и JDBC - это вполне себе подход. Простым проблемам - простой инструмент.
mad_nazgulДа хибер притащил понятие ленивость.
Что значит ленивость?
Это когда вместо реального объекта посдтавляется прокси, при обращении к которому, делается запрос и подтягиваются данные.

Без ОРМ никакой "ленивой" загрузки не надо.
Запросом вытаскиваешь данные и раскладываешь по объектам.

mad_nazgul , я не представляю как написать красивый ООП код по мотивам Rich Model без этих фичей ORM. Наверно можно, но я не представляю. Это конечно все нужно для сложный приложений с развесистой доменной моделью. Ведь чем меньше приложение, тем проще модель и меньше проблем с объектами и как их доставать из базы.

Графы объектов и ленивость
ORM позволяет нам:
1. Не писать по 20 разных методов в DAO слое по вытаскиванию разных вариантов одних и тех же объектов. В одном случае нужно одно поле, в другом - два поля и т.д.
2. Не думать о том что же будет если два разных объекта ссылаются на один и тот же. В случае JDBC нам нужно самим реализовывать PersistenceContext для того чтоб убедиться что они правда ссылаются на один и тот же объект, а не две копии этого объекта.

Dirty checks
Если предыдущие проблемы можно хоть как-то решить через пень-колоду самому написав небольшие велосипеды, то dirty checks не понятно как преодолеть. Ну, не помещая при этом всю логику в сервисы конечно. Вызвав какой-то метод доменной модели мы можем поменять очень много полей и их не вернуть return у этого метода. Какие-то объекты удалятся, какие-то добавятся. Я не знаю как эту проблему можно красиво решить без ORM.

Да, эту тему имеет смысл обсуждать только с теми у кого есть желание использовать ООП. Если пишем процедурно, то ORM и правда не так много плюшек предоставляет. Они все равно есть, но стоят ли они того чтоб изучать такой сложный инструмент..

Не спорю. Я лишь говорю о том что ORM не имеет большого смысла обсуждать если не используешь ООП.

Это не относящийся к данной дискуссии код.. Это просто API которое нам нужно использовать для получения данных из хранилища. Речь же о том как мы описываем нашу бизнес логику. Чаще всего в Java проектах логику описывают в сервисном слое реализуя то что Fowler называет Transaction Script'ом. Наши сущности (Entity) в такой схеме - это структуры данных по типу тех что есть в C. Такую модель называют Анемичной. Есть так же ООП подход который все тот же Fowler прозвал Domain Model aka Rich Model.
maytonЯ кое-что понимаю в графах. По крайней мере использовал Neptune, Jena.Речь конечно же не про абстрактную структуру данных и не про графовые QL/базы :) А просто про взаимосвязанные объекты доменной модели сохраненные (в нашем случае) в виде таблиц реляционной БД.

забыл ник, если хочешь пообщаться про Rich Model, выдели это в отдельную тему. Я шестой год пишу проект на Rich Model, очень доволен. Но я сравниваю по больше части с Transaction Script'ом, на нем проект такой сложности не представляю как бы мы писали.. забыл никООП сгинет в пучине в ближайшее десятилетиеУвы, ООП толком и не жило. Во всяком случае на Java. Вокруг в основном процедурщина.

забыл никпроблема в том что эксперты не могут договориться что же такое правильное:)Так в любом вопросе - есть теоретическая часть где философы бьются над определением идеалов, а есть прикладная часть, когда нужно сделать работу. И порою надо срезать углы, где-то надо подумать про производительность и отойти от идеалов, где-то заиспользовать какую-то некрасивую библиотеку, а где-то просто время поджимает и некогда думать.забыл никБез иронии, хотелось бы увидеть может хоть на этот раз true-oop проект успешныйНу я вот пилю один большой проект в глубоком продакшнне и один по-меньше, которым еще никто не начал пользоваться. В обоих случаях доволен. Но конечно это все закрыто. Не знаю конечно как определить "успешный", но стейкхолдеры и пользователи нас обожают.

Я использую что-то вроде DDD. Т.е. обращение к внешним хранилищам находится в сервисах/репозиториях, они собирают доменную модель, ну и вызывают у нее какой-то метод. А этот метод уже может вызывать тучу всего внутри модели, там уже десятки тыщ строк кода могут выполняться. Очень удобно тестировать: 7К тестов проходят за 10-15 мин, при том что мок-фреймворки мы не используем.

Ну и я не знаю что бы я делал без Хиба в таком проекте.

забыл никНу и что из этого Rich Model?Ну вот все что я описал. Если ты о том что вызовы к хранилищу/интеграциям не находятся в самой модели - дак это не обязательное условие (хотя приверженцы Rich Model правда часто изображают ее именно так). Вот что Фаулер об этом пишет :
FowlerOne source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer. But this isn't an argument to make the domain model void of behavior, indeed service layer advocates use a service layer in conjunction with a behaviorally rich domain model.В общем, главное чтоб сущности не были просто структурами, чтоб в них и находилась предметная логика. В моем случае это 90% кода приложения.
забыл никКак были сервисы а-ля Transaction Script так они и осталисьУ классов Transaction Script'a нет состояния. Вот он как раз просто список функций, а не полноценный класс (данные+методы).
забыл никПоложа руку на сердце - сколько раз вы в своей жизни брали класс с одного проекта и использовали в другом(особенно с rich логикой) - максимум FileUtils какойЭэ.. не понял как это связано с обсуждением. Обычно код очень специфичен для конкретного продукта. Собсно если это не так, то это скорей всего так се код. Есть конечно что-то прям очень фундаментальное для предметной области, что нужно многим приложениям - таких классов я десятки переносил.
забыл никхибера - да, он был полезен некоторое время, особенно когда были модны в энтерпрайзе админки к формам и таблицам на веб-интерфейсе, с простым CRUD и парой-тройкой связейCRUD и на обычном JDBC не сложно реализовать, там ORM не критичен.
забыл никтот же jOQQ например, если так хочется объектности, хотя и он нафиг не нужен при хорошей либе делающей удобным JDBC.JOOQ/JDBC не следят за изменениями в объектах. Я не знаю как без dirty checks сложную логику в модель можно поместить. Кстати, если две сущности ссылаются на один и тот же объект, JOOQ сможет не создавать каждому по копии?

забыл никА зачем все же мешать данные и логику в одном месте? Особенно в свете тренда java экспертов, восхваляющих иммутабельность?Не понял.. как иммутабельность противоречит состоянию+логике? Какой-то процент классов которые мы создаем в проекте спокойно умещают оба. Собсно иммутабельность именно в этом контексте и используется - когда внутри класса есть данные, но их никак не поменять. Если состояния нет, то это просто stateless классы. Вот их мы не любим.

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

забыл никПлюсов нет никаких, та же инкапсуляция достигается через сервисный слой + иммутабл records, но принося при этом кучу проблем.Не принося проблем? Ну я сходу могу сказать что тестировать такое я не захочу : либо прийдется использовать моки (нарушая инкапсуляцию потому как теперь в тестах мы знаем какие классы и методы дергает SUT; плюс сама подготовка моков, да и тот факт что мы теперь тестируем моки вместо нашего кода), либо писать высокоуровневые тесты которые сложней и медленней. Таких проектов я много видел..

Ну и иммутабл records - это противоположность инкапсуляции. Все данные торчат наружу.
забыл никЛюбой мутабельный стейт вносит в программы понятие времени, когда результат работы кода зависит от времени его вызова, это просто фантастически увеличивает количество возможных состояний системы и ведет в итоге к космической сложности и краху проектов. Зачем цепляться за этот миф?Не знаю зачем ты цепляешься за этот миф :) Immutable объекты - это хорошо, я их обожаю. И многие ООП пуристы считают что все объекты должны быть immutable. Но сам я в это не верю.. Нередко это лишний геморрой, потому как для их "модификации" (копирование старого состояния + добавления нового) требует много доп кода. Ну и это однозначно не всегда производительно (но бывает и наоборот - тогда иммутабельность это особенно радует глаз). И это при том что вся доменная модель никогда не шарится между потоками.

забыл никОдним из обещаний ООП была легкость создания small reusable objects. а-ля компоненты. Могу гарантировать что вы ни одного класса со стейтом не перенесли между проектами, в этом и весь мой поинт.Reusable внутри проекта, да. Т.е. вместо создания 10 классов под каждый случай мы можем создать 1 универсальную абстракцию. Это да, когда так получается - прям радуется сердце. Но за пределами проекта нужны другие объекты которые решают другие проблемы.

Но между проектами в одной предметной области часто есть одни и те же примитивы типа Деньги. Так же бывают общие проблемы типа экспорта в Excel. И те, и другие получается переносить между проектами. И они все с состоянием. У меня в проекте таких примитивов к примеру штук 20 - все они с легкостью переносятся в другие проекты. В общем-то надо будет библиотеки из них создать в когда-нибудь..
забыл никмне ни dirty-checks ни мутабельные объекты не впились, смотрел jOQQ только из спортивного интереса. Честно говоря не могу придумать пример где это может быть полезно, было бы интересно узнать доменную область ваших приложений что вы без них прям никак.Dirty check начинает быть важным когда объекты таки мутабельны и начинают меняться внутри. Чтоб обновить базу нужно понимать какие объекты поменялись/удалились/добавились. Я вижу только три способа это сделать в ООП:
1. Полностью иммутабельные объекты. В БД никогда не уходит UPDATE - только INSERT'ы. Во многих случаях это будет значить низкую производительность.
2. Ручной dirty check: мы где-то сохраняем состояние - какие объекты обновились. Т.е. каждый раз когда кто-то меняется - он записывает себя/свои ассоциации куда-то в коллекцию поменянных объектов.
3. Ну и то что предоставляет ORM - это автоматический dirty check. Мы сами ничего не трекаем - просто изменяем объекты как нам надо.

Я работаю в наукоемкой отрасли (химия/биология/фарма), но тут никакой специфики нет..

упс, сообщение никак не удалить :(