PD
Ну если у тебя апликуха кроме круда ничего не делает, то ок
А если аппликуха делает только круд, то хватит и простейшего JdbcDaoTemplate из того же спринга )
Size: a a a
2019 August 06
AO
А еще она даёт разработчику не думать что там за объект и откуда он, что ведёт почти всегда к проблемам
AR
Потому, что это магия завёрнутая в магию, и посыпанная пеплом кровавых интерпрайзеров.
За год работы с ним пришлось столько дерьма разгребать из-за этих вот кеширующих прокси и lazy исполнений. А так же искать причины, а что это у меня вот этот кусок кода тормозит, хмммммм
За год работы с ним пришлось столько дерьма разгребать из-за этих вот кеширующих прокси и lazy исполнений. А так же искать причины, а что это у меня вот этот кусок кода тормозит, хмммммм
ну есть такое, мы для микросервисов юзаем flyway + jdbc и счастливы )
PD
В общем, hibernate и jpa - это абстракция, которая протекает и в самых неприятных местах.
AO
Мы вообще остановились на jdbc + легенькие обёрточки
AR
В общем, hibernate и jpa - это абстракция, которая протекает и в самых неприятных местах.
+
PD
Ну, я уже сколько проектов написал на jdbc templates. А если еще PG+jsonb, то вообще сказка )
BV
В общем, hibernate и jpa - это абстракция, которая протекает и в самых неприятных местах.
Это правда, однако всё ещё это не причина отказываться от неё в любом случае
PD
Ну, протекающие абстракции - это всегда очень неожиданный и неприятный рост TCO.
BV
Ну, протекающие абстракции - это всегда очень неожиданный и неприятный рост TCO.
Как известно, любые абстракции протекают
PD
А реально решение "брать или не брать" - оно в TCO и заключается.
Хибер имеет смысл брать, если:
1) В проекте уже есть два хибер-гуру
2) В проект планируется набирать кучу джуниоров, не понимающих про БД вообще
В этом случае TCO проекта может быть ниже использования не-JPA решений.
Хибер имеет смысл брать, если:
1) В проекте уже есть два хибер-гуру
2) В проект планируется набирать кучу джуниоров, не понимающих про БД вообще
В этом случае TCO проекта может быть ниже использования не-JPA решений.
PD
Как известно, любые абстракции протекают
Не совсем и хорошие абстракции протекают в специально отведенных местах )
AO
Это правда, однако всё ещё это не причина отказываться от неё в любом случае
Ну это да, я слишком абсолютно сказал)
Скажем так, среднестатистическому проекту сложнее круда, не стоит его брать
Скажем так, среднестатистическому проекту сложнее круда, не стоит его брать
BV
Есть достаточно большой пул задач где хибернейт удобен и не создаёт особых проблем, особенно под спрингом. Конечно решение брать его в большой продакшн должно быть трижды оправданным
AO
А реально решение "брать или не брать" - оно в TCO и заключается.
Хибер имеет смысл брать, если:
1) В проекте уже есть два хибер-гуру
2) В проект планируется набирать кучу джуниоров, не понимающих про БД вообще
В этом случае TCO проекта может быть ниже использования не-JPA решений.
Хибер имеет смысл брать, если:
1) В проекте уже есть два хибер-гуру
2) В проект планируется набирать кучу джуниоров, не понимающих про БД вообще
В этом случае TCO проекта может быть ниже использования не-JPA решений.
Ой 2 пункт очень опасный, бочка пороха просто
BV
Есть достаточно большой пул задач где хибернейт удобен и не создаёт особых проблем, особенно под спрингом. Конечно решение брать его в большой продакшн должно быть трижды оправданным
В том смысле, что нужны серьёзные доводы для этого
PD
Ой 2 пункт очень опасный, бочка пороха просто
Так живет очень много аутсорсовых компаний )
Если качество проекта не является целью, то почему бы и нет.
Или если TCO заканчивается при сдаче заказчику (не планируется поддержка).
Если качество проекта не является целью, то почему бы и нет.
Или если TCO заканчивается при сдаче заказчику (не планируется поддержка).
AO
Так живет очень много аутсорсовых компаний )
Если качество проекта не является целью, то почему бы и нет.
Или если TCO заканчивается при сдаче заказчику (не планируется поддержка).
Если качество проекта не является целью, то почему бы и нет.
Или если TCO заканчивается при сдаче заказчику (не планируется поддержка).
А ну если качество и дальнейшая поддержка не нужна, то ок)
PD
А ну если качество и дальнейшая поддержка не нужна, то ок)
Так это очень большая часть рынка )
ЕС
Мы вообще остановились на jdbc + легенькие обёрточки
А как это все маппить (результат с бд на объекты натягивать) там же столько бойлерплейта писать (и столько же при любых изменениях)?