Comments 2
Что за кошмар, дырявые абстракции все дырявее и дырявее.
"упрощая многие распространенные запрос"- просто объясните мне в чем сложность сделать обычную выборку или
jsonb_build_object(нужные поля, агрегации в массивы, что угодно )?
Вот какую задачу решают ОРМы?
Помнить про ленивую инициализацию?
Любиться с кривыми селектами в базу?
Апдейтать все поля целиком вместо инкремента 1го столбца?
Стимулировать использовать единый обьект в любых ситуациях, даже когда нам нужны всего пару полей?
Бугурт вышел немного агрессивный, но полностью согласен с каждым предложением.
ОРМ в большинстве случаев кажется абстракцией ради абстракций. Перешёл на чистый jdbc у себя в проекте, чтобы избавиться от оверхеда JPA и Hibernate, и оказалось что ничего не изменилось, а кое-где стало лучше:
точно знаю какой java-код выполняется
точно знаю какие SQL запросы идут в базу и имею полную свободу их оптимизации
Слой общения с БД теперь по-настоящему отделён от слоя логики
Мой проект если что простенький, можно сказать CRUD. Я знаю допустим что транзакции JPA могут много где пригодиться в больших сложных проектах.
Но большинство бэкендов всё же именно как у меня, и больно смотреть как ради генерации маппинга тянут весь Hibernate.
Выражение Hibernate запросов в виде типо‑безопасных Java-потоков