Навчання · 23 вересня 2016, 10:01 4513

Саша Чепурной, Java developer

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

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

Теми: Hibernate, JPA

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Oleg Kariakin Senior Java Developer 26.09.2016 12:30

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

Відповісти

Підтримати

Нестор Иванович 26.09.2016 00:48

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

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

Відповісти

Підтримати

Олексій Пєніє 26.09.2016 00:21

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

Відповісти

Підтримати

Саша Чепурной Java developer 26.09.2016 00:24

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

Відповісти

Підтримати

Олексій Пєніє

Антон Капустин 25.09.2016 13:06

www.amazon.com/...ersistence with Hibernate

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 25.09.2016 11:27

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

Відповісти

Підтримати

anonymous 24.09.2016 20:52

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

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 24.09.2016 22:42

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

Відповісти

Підтримати

undefined pointer 25.09.2016 00:23

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

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

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

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

Відповісти

Підтримати

Mykola Gurov тролль 25.09.2016 11:07

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

вброс не раскрыт.

Відповісти

Підтримати

undefined pointer

undefined pointer 25.09.2016 14:07

начните с
rich vs anemic

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

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

Відповісти

Підтримати

Oleksandr Olgashko 23.09.2016 12:56

www.toptal.com/...ibernate-ruined-my-career

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 23.09.2016 13:21

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

Відповісти

Підтримати

Oleksandr Olgashko

Mykola Gurov тролль 23.09.2016 15:56

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

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 23.09.2016 16:49

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

Відповісти

Підтримати

Mykola Gurov тролль 25.09.2016 11:09

Hibernate нужно использовать только тогда, когда у вас сложная модель данных

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

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 25.09.2016 11:17

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 25.09.2016 11:33

Сложная доменная модель, связи. Так суть в том, что если не большая нагрузка и данных не много — то проблемы особо не будут заметны.

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

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 25.09.2016 12:06

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

Відповісти

Підтримати

Syphilis Candidos 25.09.2016 14:55

Кто мешает внедрить CQRS?

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 25.09.2016 15:33

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

Відповісти

Підтримати

Syphilis Candidos

undefined pointer 23.09.2016 21:39

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

Відповісти

Підтримати

Mykola Gurov тролль 25.09.2016 11:06

Потому что проект уже на нем.

рефакторинг не, не слыхал? Чем раньше тем проще, конечно.

Відповісти

Підтримати

undefined pointer

Bogdan Shyiak SE or Dev 25.09.2016 11:27

рефакторинг не, не слыхал? Чем раньше тем проще, конечно.

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

Відповісти

Підтримати

Mykola Gurov тролль 25.09.2016 12:03

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

никто не обещает что это будет совсем просто. Очень помогает загнать базу в докер и запускать вместо моков при прогоне тестов. Даже с Ораклом работает.

Отсюда имеем что цена такого рефакторинга (уже после 3-6 итереций разработки) переводит его в разряд невозможного.

Divide and conquer. Ничто не заставляет переводить все одним махом, да и рискованно это.

«что делать с проблемами хибера мы уже знаем, а вот как исправлять проблемы мега-крутого-дата-аксес-фреймворка нам еще не известны»,

по-этому лучше раньше и проще.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 25.09.2016 14:11

никто не обещает что это будет совсем просто.

Отсюда имеем что цена такого рефакторинга (уже после 3-6 итереций разработки) переводит его в разряд невозможного.

---

по-этому лучше раньше и проще.

Угу, дорогой бизнес, мы дропаем половину бизнес-фич, чтобы выкосить хибер, который __возможно__ создаст проблемы в будующем.
Подобные проблемы решаются, как правило, когда они стоят уже очень остро. А на познем этапе, эффективнее не рефакторить такую проблему, а пытаться изолировать.
.
К слову, я не вижу большой проблемы с хибером. Да, хибер — это кусок гуана. Но простые вечи он решает. А сложные вполне можно решать напрямую запросами, даже через тот же хибер. Основная сложность — это не смешивать код с запросами и код с использованием JPA.

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 25.09.2016 15:19

Да, хибер — это кусок гуана.

Ну я б не стал так категорично высказываться Богдан, я к примеру так не считаю. Да и могу сказать вам, что я участвовал в написании нескольких банковских проектах, которые успешно работают в продакшене, с нормальным перформенсом, и они со сложной бизнес логикой и связями, и кол-во данных с тысячным порядком. Главное уметь пользоваться инструментом, в том числе как и вы пишете —

сложные вполне можно решать напрямую запросами

Відповісти

Підтримати

Andriy Krot Software Engineer в IonIdea 26.09.2016 11:54

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

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 26.09.2016 12:10

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

Відповісти

Підтримати

Andriy Krot Software Engineer в IonIdea 26.09.2016 12:20

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

Відповісти

Підтримати

undefined pointer 25.09.2016 14:09

рефакторинг не, не слыхал?

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

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

Відповісти

Підтримати

Дмитро 24.09.2016 11:25

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

Відповісти

Підтримати

Oleksandr Olgashko

Igor Dmitriev Founder, CEO в Softa 23.09.2016 11:27

Добрый день Александр, то что вы не понимаете — это норма, через это проходит много разработчиков, другой вопрос — как глубоко вы готовы зайти. Мой совет для вас, посмотрите вот эти видео, если еще не видели:
1.
2.
3.
4.
5.

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

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

Відповісти

Підтримати

Саша Чепурной Java developer 23.09.2016 11:30

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

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 23.09.2016 11:31

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

Відповісти

Підтримати

Саша Чепурной

Eugene Suleimanov Senior Software Engineer/Team Lead 24.09.2016 00:29

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

Відповісти

Підтримати

Mykola Gurov тролль 23.09.2016 11:02

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

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

Відповісти

Підтримати

Sergiy Morenets Java evangelist 23.09.2016 14:39

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

Відповісти

Підтримати

Artem Astafyev Solution Architect в DataArt 23.09.2016 15:10

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

Відповісти

Підтримати

Sergiy Morenets

Mykola Gurov тролль 23.09.2016 15:50

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

Відповісти

Підтримати

Sergiy Morenets

Artem Astafyev Solution Architect в DataArt 23.09.2016 15:09

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

Відповісти

Підтримати

Oleksandr Burchak Sr Java developer/Application Architect 25.09.2016 10:21

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

Відповісти

Підтримати

Artem Astafyev Solution Architect в DataArt 25.09.2016 12:00

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

Відповісти

Підтримати

Oleksandr Burchak

Igor Dmitriev Founder, CEO в Softa 25.09.2016 12:14

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 25.09.2016 14:02

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

Каждый новый уровень абстракции должен упрощать работу.
Если фреймворк требует чтобы «на его изучение уделяли должное время», то он поломан. И тут не важно это хибер или другой фреймворк.

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

Не-не. В интернетах есть 2 типа людей:
1) которые могут только жаловаться;
2) которые могут только указывать, чтоб другие не жаловались :)

Відповісти

Підтримати

Igor Dmitriev Founder, CEO в Softa 25.09.2016 14:35

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

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

мой ответ — понять, принять, простить и учить.

Відповісти

Підтримати

Oleksandr Burchak Sr Java developer/Application Architect 25.09.2016 13:42

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

Відповісти

Підтримати

Artem Astafyev Solution Architect в DataArt 25.09.2016 17:08

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

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

Так чтоб 1000 таблиці в связях многие-ко-многим, так чтоб ли?

Я свои аргументы привел, в ответ только троллинг.

Відповісти

Підтримати

Oleksandr Burchak

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

Ваша пошта

Не підписуватись