Насколько полезен Hibernate? Сильно ли он упрощает работу?

Question

[Urukhayy]

Насколько полезен Hibernate? Сильно ли он упрощает работу?
Желательно привести яркие примеры.

В некоторых статьях по Hibernate используются SQL-запросы. Тогда зачем используется Hibernate, если он не берёт на себя полностью автоматическое обслуживание БД?
Также в некоторых статьях, постоянно открываются сессии, производятся действия с классом, и закрываются сессии. Разве это не прибавляет работы разработчику? Может ли Hibernate работать так, чтобы при вызове сеттера в классе без созданиях всяческих сессий он автоматически бы обращался к БД?

Не проще ли в некоторых случаях вместо постоянного открытия сессий написать MySQL запрос?

Answer 1

[sirs]

Полезен или нет зависит от вашего проекта. Если у вас парочка сущностей и 10 методов, в которых идёт обращение к базе - тогда хибернейт вам не нужен. Если у вас большой, растущий проект, где десятки и сотни сущностей и много CRUD операций - без JPA, hibernate, spring data и т.д. вам не обойтись. Хибернейт сильно упрощает жизнь в простых вещах, но сильно усложняет в сложных. Также можно рассмотреть профит применения хибернейта как получение кэша нескольких уровней из коробки.
Посмотрите литературу в общем по ORM проблеме и JPA, без привязке к конкретной реализации, которой и является хибернейт.

П.С. А добавлять какой-то код или логику в сеттеры я бы крайне не рекомендовал. Есть набор заповедей хорошего разработчика - SOLID, первый принцип - Single responsibility - "каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс". А в вашем случае есть какая-то модель/бин - который в полях содержит данные - это и есть его единственная обязанность, а логика по чтению-записи в базу не должна этот объект интересовать в принципе.

Answer 2

[svsanek]

Смотри. Что дает Hibernate - мапинг объектов на реляционную базу. И тут сразу куча вопросов - а как отображать ООП на реляционную модель (где нет наследования, инкапсуляции, полиморфизма). Отсюда много сложностей. Еще возникают такие вопросы - ты получил объект из базы, передал его в какой-нибудь UI - там 10 раз поменяли одно и то же поле - так 10 раз делать апдэйт базы или один? Хайбернейт должен догадаться или программист ему подсказать. Отсюда появляются всякие циклы жизни сущности, кэши и куча всякой дополнительной головной боли. Это если не касаться наследования, отношений один к одному, многие ко многим.
Мой вердикт - хайбернейт несет много дополнительной нагрузки - не зря по нему столько книг написано.
Но у него есть и плюсы

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

Итак плюсы
1. Ты продолжаешь работать с объектной моделью и забываешь про все эти 100000+ строк sql запросов.
2. Тебе легко добавлять новые сущности, рулить транзакциями, про оптимизацию думают за тебя (кэши)
3. Ты вообще забыл что такое джойны и по каким полям. Ты начинаешь верить в волжебство. Квэри билдеры просто сумасшедшие. А на груви код в одну строку просто сводит с ума!
4. У тебя реально много таблиц (сущностей)
5. Ты познал хайбернейт и оформил код конвеншн на проекте и вообще забыл, что такое проблемы

Минусы
1. Если у тебя 2 таблицы - нафига тащить тонну сложностей в свой проект. Посмотри книги по хайбернейту. Книга только по одной технологии джава. Целая книга!!!
2. Ты должен четко понимать цикл жизни сущности. Когда она в сессии, когда нет, как она попадает в сессию, что с кэшем, а если у сущности релейшеншипы, а если лэйзи лоадинг. Просто тонна всего.
3. Ты понимаешь, что ты перестаешь рулить запросами - и что-то оптимизировать нереально сложно. Что в sql правиться одной строчкой - используя хайбернейт неудивительно если ты перепишешь всю иерархию наследования с попутным рефакторингом контроллеров, юйа и т.д.
4. В один момент ты можешь понять, что пропустил тему с лэйзи лоадингом и начал класть на лопатки оракл. А знающие люди подскажут сколько стоит это поправить.
5. И да. Если тебе нужен перформанс - пиши запросы сам. ORM тут явно не подойдет.

По-этому - просто составь табличку плюсов и минусов и реши.
Хайбернейт крут, только когда он обоснован

Answer 3

[⚡ Kotobotov ⚡]

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

Answer 4

[poisonGreen]

Советую посмотреть по этой теме видео