Hibernate Dooms Your Code

This thoughts come from here.

Первые базы данных были иерархическими. Это было отстойно.
Был только один путь работы с данными, в порядке их хранения.
Любая попытка изменить точку зрения на данные, это тонны ручной
работы. Потом появились реляционные базы данных и SQL
и это барьер исчез. С SQL не важно как хранятся данные,
их можно выбрать в любом виде, в любом количестве, и в любой форме.

Принципиально, SQL даёт возможность работать с данными представленными
в совершенно произвольной структуре, - в том виде в котором данные
нужно для работы. Для чтения совершенно не важно как данные
хранятся, в одной таблицу, двух, трёх, в N строках одной таблицы.
Можно использовать сырые данные, можно их связывать,
можно их агрегировать.

Более того, SQL возволяет редактировать данные в произвольном
формате, а не в том в котором они реально хранятся в базе.
Если нужно обновить 2 поля - не нужно перезаписывать
все 44 старыми значениями. Это не вопрос производительности.
Это вопрос понимания того что происходит. Есть рызница между
методами loadMoneyIntoAccount() и save().

SQL даёт возможность читать данные не в том формате
в котором они хранятся. SQL даёт возможность изменять
данные не в том формате в котором они хранятся.
И - те данные которые мы считываем - совершенно не те
данные которые мы записываем. То есть да, они могут
совпадать, но это будет вырожденный случай - это
будет просто означать что данные не содержать в себе
логический связей - то есть в приложении нет логики,
оно просто читает набор полей и записывает тот же набор.

Предположим, что логика всё таки есть.

И тут важно - что бы логика работала без ошибок.
Но что для этого нужно?

Immutable State.

Если что то не изменяется - на это можно положиться.
Неизменные данные гарантируют что логика на них
построенная не будет разрушена каким то логически
не связанным кодом, который вдруг выпрыгнул из
за угла и что то поменял в entity bean.

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

К чему я всё это.



Что "даёт" Hibernate (ActiveRecord, what ever).
0. Mutable данные.
1. Жёсткий маппинг таблиц базы на бины данных, зато быстро.
2. Абстрагированный от базы язык запросов.
3. Отложенное сохранение.
4. Ленивую подгрузку данных.
5. Кеширование бинов данных.
7. Сессию.


Но как это работает в действительности.

Жёсткий маппинг - мы вынуждены работать с данными
в том виде в котором они хранятся. Почему? Читать и
записывать данные можно в одном и том же формате,
как будто у них нет структуры. Но она есть!

Абастрагирование от базы данных - смысл?
Оно же всё равно не работатет. Код полностью
абстрактный от базы - это нечто тупое как бревно.
Если он упрётся в проблемы с производительностью
смена базы решит её? Нет. Я вообще сомневаюсь
что смена базы может решить какие то проблемы.
Разве что вы до сих пор сидите на Interbase.

В итоге всё равно там где нужно сделать реально
сложный вопрос пишется SQL, который всё равно
переделывать при смене базы. Зато логика работы
с базой оказывается разбросанной по всему коду - где
только можно сохранять бины. Вот это самое стрёмное.

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

Ленивая подргузка данных - О ДА, МЫ МОГЁМ.
Давайте сначала запамим базу 1-1 на бины,
потом завяжем их связями так тесно что загрузка
одного объекта потребует регурсивно выгрести
из базы ВООБЩЕ ВСЁ ЧТО С НИМ СВЯЗАНО.
А потом посмотрим на это и скажем, "хммм, что то тормозит".
И тут к нам приходит спасение в виде ленивой загрузки.
Лично я не просил.

Кеширование в Hibernate. Честно, ни разу не видел что бы
у Hibernate кэш был включен. Я видел как его пытались
включать. Но не надолго. Как минимум потому что не всё идёт
через Hibernate. Что то сохрянется для скорости через
хранимики, или есть отдельная нода с фоновыми задачами,
или что угодно. А кэш нужно инвалидировать. Это так сложно
тестировать. А без него всё работает и так быстро.
Так ну его нафиг.

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

Сессия - да, сессия нужна для кеширования, а ещё для ленивой
подгрузкуи. Есть одна проблема. Для логики приложения
она нафиг не нужна. И либо её нужно тащить через все бизнес-методы
чего никто не делает, либо делать её thread-local - тогда вся логика
работы с данными оказывается заперта в одной нитке.
Спрашивается - чего это, почему я не могу распарралелить логику.


Да, ещё один момент про энтити-бины. Поскольку они
используются не только для представления но и для
редактирование - есть большой соблазн реализовать
логику редактирования прям в контроллере (MVC).
Бизнес логика - ну нафиг. Значит мы делаем ВЬЮ,
модель это значит энтити бины эти, а в контроллере
мы что - выставить чек-бокс, проверить что имя не пустое,
сохранить данные кредитки. И желательно что бы до
и после session.save() было как можно больше
интерфейсного кода в одном методе.
А ТО НЕ ИНТЕРЕСНО БУДЕТ БИЗНЕС ЛОГИКУ
ТЕСТИРОВАТЬ, СЛИШКОМ ПРОСТО.


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

Что бы всё это хоть как то работало, придумывается
кэш который мало того что сложно использовать
так он и вообще не нужен поскольку прямая работа
с базой и так в 10 раз быстрее, и ленивая подгрузка
которая запирает объекты в сессии - и фиг ты передашь
из него данные куда ни попадя без загадочных телодвишений
типа .getChildsList();

К чему я всё это: используйте mybatis,
ну или JdbcTempate на худой конец.