Hibernate (JPA) или как с этим жить?

Чем дальше я работаю с хибернейтом (не на прямую, а через Spring Data, но все же) тем больше я понимаю, что ничего не понимаю. Пересмотрел лекций по тюнингу хибера, разнообразные грабли, документации и т.д. и все равно каждый день выползают проблемы. Может кто-то может посоветовать годные материалы по работе с хибернейтом, или проекты с открытым кодом? Как подходить к маппингам, если в одной сущности, к примеру, у меня должны быть ссылки на еще 2 коллекции других сущностей. С джоинами такое решать как-то не очень, а если доставать много записей на каждую коллекцию subquery — выходит много. Какие практики у нормальных людей для работы с ORM?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

www.youtube.com/watch?v=H8z24T09lMQ
Н. Алименков “За что я ненавижу Hibernate”

работа девелопера- боль
Java Persistence with Hibernate тут ниже уже посоветовали почитать для просветления

я вон вообще живу с велосипедом который дает только обертки для type-safe & db agnostic sql фактически и все.

Возьми с гитхаба готовый проект, смотри как там, и не велосипедийствуй.

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

в тему комментарий Gavin King (создателя Hibernate):
www.reddit.com/...me_just_learn_sql/cjheyec

Как раз пишу статью про альтернативу хиберу — jooq.

понятно, что есть альтернативы как jooq, mybatis, spring jdbc template, jcabi-jdbc и другие, но это уже другая история, да и там тоже не все гладко.

Он не альтернатива хиберу никак.

Главная идея ORMов — обеспечение соответствия модели и ее хранения в БД. Отказ от этого переводит решение в другую категорию.

Отказ от хибера оправдан в случаях
— разделения, расхождения модели данных и домейн модели
— требованиям к быстродействию, обычно это потребность в bulk операциях
— модели и связи между ними просты

Если же этих случаев нет, то вряд ли имеет смысл в более низкоуровневой, чем хибер, работе с бд.

Он не альтернатива хиберу никак.
вброс не раскрыт.

начните с
rich vs anemic

может тогда поймете почему одно другому НЕ альтернатива — никак.

а выбор первого или второго подходов должен осуществляться на формализованных инженерных требованиях.

xpinjection.com/...ur-project-no-it-was-you
Суть такова что нужно хорошо знать инструмент с которым работаешь, а не просто обвинять его, большинство разработчиков обладают знаниями хибернейта лишь на уровне понаставлять аннотации и на этом все заканчивается, и это печально.
«A fool with a tool is still a fool»

Типа да. Но вот только если хорошо знать Хибернейт, со всеми его подводными камнями, да помноженными на причуды query optimizer’a со стороны базы — не будет ли в сумме проще напрямую, без него?

Нужно понимать когда следует использовать Hibernate, а когда — нет, но к сожалению многие архитекторы этого не понимают и внедряют его всюду, так как Hibernate это самый популярный ORM фреймворк.
Я считаю что Hibernate нужно использовать только тогда, когда у вас сложная модель данных, данных не много, маленькая нагрузка или когда вам не важен перформенс.

Hibernate нужно использовать только тогда, когда у вас сложная модель данных
сложная в смысле много аттрибутов у сущностей, или разветвленная со многими связями? Если первое — то не важно, если второе — то укусит еще больнее, ИМХО.

Сложная доменная модель, связи. Так суть в том, что если не большая нагрузка и данных не много — то проблемы особо не будут заметны. Да и в целом как показывает практика Hibernate хорош на вставку, но к сожалению не очень эффективен на чтение, со всеми N+1, Cartesian product, и так далее.

Сложная доменная модель, связи. Так суть в том, что если не большая нагрузка и данных не много — то проблемы особо не будут заметны.
Ага, если вы правильно __для всех случаев__ прописали каскады.
Суть проблемы в том что для сложных связей вам надо балансировать между:
1) Поднятием большого количества сущностей из БД для сохранения каждой из них.
2) Раскрытием структуры БД прямо к коде бизнес-логики (например, некоторые сущности будут иметь ИД другой сущности вместо ссылки на него). И как бонус к этому ручные сохранения и флаши. Что нивелирует основное преимущество хибера.

Это разве проблема? Если вы не понимаете эти вещи — то вам лучше не использовать Hibernate вообще. Хотел бы посмотреть как вы будете разруливать весь этот маппинг связей руками.

Я ж не против, в этом вся и суть, что люди взяв Hibernate, используют только сущности, избегая bulk операций например. Можно и CQRS, отличный подход. Я и не считаю, что N+1 и Cartesian product это большие проблемы, причем это не проблемы фреймворка, это люди не задумываются когда пишут код, это чистой воды ошибка программиста. Опять же повторюсь — это не инструмент плохой, это люди не задумываются что пишут.

а это обычно невозможно проверить. Потому что проект уже на нем. А если новый — то будет выбран он, потому что так положено, традиция, лучшие практики, заказчик просит, и т.п.

Потому что проект уже на нем.
рефакторинг не, не слыхал? Чем раньше тем проще, конечно.
рефакторинг не, не слыхал? Чем раньше тем проще, конечно.
У вес проблема? У меня есть решение: вы должные решить вашу проблему и ее не будет :)
Загвоздка в том что хибер — это уровень доступа к данным, этот уровень как правило не очень хорошо покрыт тестами (особенно негативные сценарии). А те тесты которые есть на бизнес-логику как правило мокируют слой доступа к данным, то есть вам еще и их прийдется менять.
Отсюда имеем что цена такого рефакторинга (уже после 3-6 итереций разработки) переводит его в разряд невозможного.
Ну и проблема которую описал Sergiy Skyninko: «что делать с проблемами хибера мы уже знаем, а вот как исправлять проблемы мега-крутого-дата-аксес-фреймворка нам еще не известны»,
переводит такой рефакторинг еще и область бессмысленных.
Загвоздка в том что хибер — это уровень доступа к данным, этот уровень как правило не очень хорошо покрыт тестами (особенно негативные сценарии). А те тесты которые есть на бизнес-логику как правило мокируют слой доступа к данным, то есть вам еще и их прийдется менять.
никто не обещает что это будет совсем просто. Очень помогает загнать базу в докер и запускать вместо моков при прогоне тестов. Даже с Ораклом работает.
Отсюда имеем что цена такого рефакторинга (уже после 3-6 итереций разработки) переводит его в разряд невозможного.
Divide and conquer. Ничто не заставляет переводить все одним махом, да и рискованно это.
«что делать с проблемами хибера мы уже знаем, а вот как исправлять проблемы мега-крутого-дата-аксес-фреймворка нам еще не известны»,
по-этому лучше раньше и проще.
никто не обещает что это будет совсем просто.
Отсюда имеем что цена такого рефакторинга (уже после 3-6 итереций разработки) переводит его в разряд невозможного.
---
по-этому лучше раньше и проще.
Угу, дорогой бизнес, мы дропаем половину бизнес-фич, чтобы выкосить хибер, который __возможно__ создаст проблемы в будующем.
Подобные проблемы решаются, как правило, когда они стоят уже очень остро. А на познем этапе, эффективнее не рефакторить такую проблему, а пытаться изолировать.
.
К слову, я не вижу большой проблемы с хибером. Да, хибер — это кусок гуана. Но простые вечи он решает. А сложные вполне можно решать напрямую запросами, даже через тот же хибер. Основная сложность — это не смешивать код с запросами и код с использованием JPA.
Да, хибер — это кусок гуана.
Ну я б не стал так категорично высказываться Богдан, я к примеру так не считаю. Да и могу сказать вам, что я участвовал в написании нескольких банковских проектах, которые успешно работают в продакшене, с нормальным перформенсом, и они со сложной бизнес логикой и связями, и кол-во данных с тысячным порядком. Главное уметь пользоваться инструментом, в том числе как и вы пишете —
сложные вполне можно решать напрямую запросами

Счет зваисей на тысячи — это маленькая базка. В тех ж кбагковских проектах могут приходить тысячи записей в секунду, и там ничего близкого к любой ОРМ просто нет.

Все относительно, не нужно тут меряться достоинствами, для кого-то и 100 тысяч записей это мало. Главное чтоб ваше приложение было масштабируемым. Что вы имеете ввиду приходит тысячи записей в секунду? откуда приходит? поясните пожалуйста, а то как-то странно выглядит.

Ордера, трейды, экзекушины и прочее. Биржевая информация.
Она должна быть обработана и сохранена очень быстро.
Что касается масштабируемости ЖПА — это ведь шутка была, да?

рефакторинг не, не слыхал?
подсистемы работы с БД?
а так как «предлагается» отказаться от жирных моделей хибера, в пользу тонrих от X — то такой рефакторинг потянет за собой и рефатокринг подсистем с бизнес-логикой. а ее рефакторинг потянет...

вы герой что-ля плюс с бесконечным бюджетом?

После прочтения вывод напрашиваеться такой, что неудачную архитектуру приложения проще костылять используя Plain sql, а не Hibernate? Странно что 4 года назад товарищ не подсказал, что проекты масштабов гугла и фейсбук обычно не используют реляционные базу для записи чтения одновременно.

Добрый день Александр, то что вы не понимаете — это норма, через это проходит много разработчиков, другой вопрос — как глубоко вы готовы зайти. Мой совет для вас, посмотрите вот эти видео, если еще не видели:
1. www.youtube.com/watch?v=-EpP0Vo63FM
2. www.youtube.com/watch?v=V-ljsrVy6pE
3. www.youtube.com/watch?v=eodwKFs6bR4
4. www.youtube.com/watch?v=YzOTZTt-PR0
5. www.youtube.com/watch?v=BTdTEe9QL5k

Так же большой совет почитать вот эту книгу — Java Persistence with Hibernate 2nd edition 2016, если вы действительно хотите хорошо разбираться с данным фреймворком.
А так же советую почитывать вот этот замечательный блог Влада Михальча — vladmihalcea.com
Этот Влад так же написал книгу — HIGH-PERFORMANCE JAVA PERSISTENCE.

Выход всегда есть :)

3-е не видел, спасибо большое за материалы!

Пожалуйста, обращайтесь если что :)

Спасибо за интересный материал, коллега.

Лучше с ним не жить вообще, по возможности. В том смысле, что он должен упрощать маппинг объектов в реляции. Если же он становится между тобой и базой, лучше его выбросить и работать только с базой. ИМХО.

Из личной практики, работать с ним легко и удобно только на этапе пилотов/прототипирования. Как только начинается реальная нагрузка и изменения требований, то ну его нафиг к этому еще добавлять глюкавую прослойку.

А что же вы используется в качестве DAO? JDBC?

Да, JdbcTemplate в большинстве случаев устраивает.

Spring’овый JdbcTemplate в основном + несколько хелперов чтобы в инсертах не повторяться. Несколько больше возни поначалу, но потом и читаемо и поддерживаемо легко.

Полностью поддерживаю. А кто хоть раз заходил в отладке во внутренности хибера, уже точно 10 раз подумает перед его использованием.

Заходил. И даже місли не возникало отказаться от Хибера. Смотрю, тут много сказочникоа собралось.

Вполне возможно, такие люди здесь есть. Это те люди, которые не использовали хибер в реально сложных задачах. Вот Николай хорошо и по пунктам все это разложил www.youtube.com/watch?v=YzOTZTt-PR0. И это только часть проблемы.

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

если вы просто взяли фреймворк и не уделили ему должного времени для изучения и потом жалуетесь что он такой сякой — то это ваша проблема,
Каждый новый уровень абстракции должен упрощать работу.
Если фреймворк требует чтобы «на его изучение уделяли должное время», то он поломан. И тут не важно это хибер или другой фреймворк.
Учитывая тот факт что это опен сорс проэкт, так если вы видите какие-то проблемы в нем — сделайте контрибут, пожалуйста, никто не мешает. А у нас люди только жаловаться могут.
Не-не. В интернетах есть 2 типа людей:
1) которые могут только жаловаться;
2) которые могут только указывать, чтоб другие не жаловались :)

Ну так Hibernate же упрощает работу, не нужно теперь маппить и знать sql, все круто :)
На самом деле получается что оно так и есть, пока дело не доходит до более менее сложных задач, если у вас CRUD приложение, то все ок. Ну и так же нужно учесть факт что нельзя так просто взять и написать крутой код. Сама идея написать фреймворк который будет работать для любых баз данных уже не так проста.
И как получается, почти все фреймворки, которые дают более высокую абстракцию, и вроде как помогают ускорить разработку, в итоге выливаются в то, что много времени, которое ты сэкономил приходится тратить на изучение его и написание воркэраундов багов.
Я сам не считаю что хибер идеальный фреймворк, мир не идеален.
Но реалии таковы что хибер заполнил рынок уже очень основательно, и на большинстве проэктах он используется, а так же исходя из темы данного топика —

Hibernate (JPA) или как с этим жить?
мой ответ — понять, принять, простить и учить.

Реально — насколько? Так чтоб 1000 таблиці в связях многие-ко-многим, так чтоб ли? Если ваш вібор #1 — jdbc, я сочуствую и вам, и вашей команду, и вашему продакт оунеру.

Реально — насколько? Так чтоб 1000 таблиці в связях многие-ко-многим, так чтоб ли? Если ваш вібор #1 — jdbc, я сочуствую и вам, и вашей команду, и вашему продакт оунеру.
Про выбор № 1 никто не говорил, а инструмент нужно использовать с умом и в тех случаях, где это будет оптимально, а не только потому, что его используют все и это считается круто.
Так же сочувствую продакт оунеру, которому выбор хибера мотивируют не аргументами, а фразой
Так чтоб 1000 таблиці в связях многие-ко-многим, так чтоб ли?
Я свои аргументы привел, в ответ только троллинг.

Підписатись на коментарі