Мне нужно освоить современный уровень ORM под JVM.
Я так понял, что промышленным стандартом является Hibernate (если не прав — поправьте).
Но когда я в последний раз писал что-то на джаве, Хибер ещё писался в памперсы. Поэтому у меня с ним опыта нет.
Попробовал поискать тьюториалы гуглом — нет уверенности, что они адекватные. Как-то стрёмно код выглядит, хочется убедиться, что я не изучаю столетней давности версию
Заранее благодарен.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Мне нужно освоить современный уровень ORM под JVM. S>Я так понял, что промышленным стандартом является Hibernate (если не прав — поправьте). S>Но когда я в последний раз писал что-то на джаве, Хибер ещё писался в памперсы. Поэтому у меня с ним опыта нет. S>Попробовал поискать тьюториалы гуглом — нет уверенности, что они адекватные. Как-то стрёмно код выглядит, хочется убедиться, что я не изучаю столетней давности версию S>Заранее благодарен.
https://hibernate.org/orm/documentation/5.4/ ? Лично я всегда User Guide смотрю по нужным вопросам, но у меня некоторое знакомство с ним уже есть. Ещё посоветую mkyong.com шикарный сайт, по всем вопросам, связанным с Java там есть качественные материалы.
Насчёт промышленного стандарта — у меня такое ощущение, что многие пользуются простыми библиотеками вроде Spring JDBC, jOOQ, JDBI и тд. А ORM-решения в Java-мире имеют определённую плохую славу (имхо из-за пресловутого Hibernate). Но может быть ошибаюсь.
Здравствуйте, vsb, Вы писали:
vsb>Насчёт промышленного стандарта — у меня такое ощущение, что многие пользуются простыми библиотеками вроде Spring JDBC, jOOQ, JDBI и тд.
Хм, а как на этих простых решениях классы с коллекциями потом делать ? Ну получим мы результат SELECT — JOIN, а разбирать его на Parent — List<Child> потом вручную ?
>А ORM-решения в Java-мире имеют определённую плохую славу (имхо из-за пресловутого Hibernate). Но может быть ошибаюсь.
Возможно. Кстати, есть MyBatis — SQL он в отличие от Hibernate не генерирует, но в класс и его коллекции маппит.
Здравствуйте, Pavel Dvorkin, Вы писали:
vsb>>Насчёт промышленного стандарта — у меня такое ощущение, что многие пользуются простыми библиотеками вроде Spring JDBC, jOOQ, JDBI и тд.
PD>Хм, а как на этих простых решениях классы с коллекциями потом делать ? Ну получим мы результат SELECT — JOIN, а разбирать его на Parent — List<Child> потом вручную ?
Обычно в каждом варианте есть какие-то решения для простых случаев. Например для Spring JDBC есть примеры тут (BeanPropertyRowMapper). Именно Parent — List<Child> наверное придётся вручную, но просто поля промаппить можно быстро. В целом да, готовиться вручную каждое поле ставить, в общем случае это так.
>>А ORM-решения в Java-мире имеют определённую плохую славу (имхо из-за пресловутого Hibernate). Но может быть ошибаюсь.
PD>Возможно. Кстати, есть MyBatis — SQL он в отличие от Hibernate не генерирует, но в класс и его коллекции маппит.
Да, это тоже нормальный вариант, есть опыт использования.
Здравствуйте, Sinclair, Вы писали:
S>Мне нужно освоить современный уровень ORM под JVM. S>Я так понял, что промышленным стандартом является Hibernate (если не прав — поправьте). S>Но когда я в последний раз писал что-то на джаве, Хибер ещё писался в памперсы. Поэтому у меня с ним опыта нет. S>Попробовал поискать тьюториалы гуглом — нет уверенности, что они адекватные. Как-то стрёмно код выглядит, хочется убедиться, что я не изучаю столетней давности версию S>Заранее благодарен.
Но как верно отметили, кроме Хибера в Джаве есть и другие ORM. MyBatis, Jooq.
С MyBatis я несколько лет работал, и мне он не понравился, у него есть ряд нерешенных проблем, которые серьезно ограничивают разработчика.
Мне кажется, Хибер — самая зрелая технология.
Здравствуйте, vsb, Вы писали:
PD>>Возможно. Кстати, есть MyBatis — SQL он в отличие от Hibernate не генерирует, но в класс и его коллекции маппит.
vsb>Да, это тоже нормальный вариант, есть опыт использования.
Вот именно что "нормальный". При попытке использовать его более продвинуто или гибко начинаются всякие неприятные препоны. Если проект планируется вывести на серьезный уровень, лучше обходить MyBatis стороной.
Здравствуйте, Sinclair, Вы писали:
S>Мне нужно освоить современный уровень ORM под JVM.
Современный уровень — полноценные ORM с контролем модификации объектов (JPA/Hibernate) применяют в RAD проектах или проектах с неквалифицированными разработчиками. Причина — высокая сложность, высокая хрупкость, ограниченное быстродействие.
Качественные проекты пишут без ORM на JDBC, простых обертках над ним (spring jdbctemplate), или на JOOQ
Здравствуйте, Sinclair, Вы писали:
S>Попробовал поискать тьюториалы гуглом — нет уверенности, что они адекватные. Как-то стрёмно код выглядит, хочется убедиться, что я не изучаю столетней давности версию
Здравствуйте, scf, Вы писали:
S>>Мне нужно освоить современный уровень ORM под JVM.
scf>Современный уровень — полноценные ORM с контролем модификации объектов (JPA/Hibernate) применяют в RAD проектах или проектах с неквалифицированными разработчиками. Причина — высокая сложность, высокая хрупкость, ограниченное быстродействие.
"высокая сложность, высокая хрупкость, ограниченное быстродействие" чего именно?
Здравствуйте, scf, Вы писали:
G>>"высокая сложность, высокая хрупкость, ограниченное быстродействие" чего именно?
scf>Hibernate, конечно. Впрочем, EclipseLink ненамного лучше.
А в чём тогда логика твоего тезиса? "высокая сложность, высокая хрупкость, ограниченное быстродействие" — *причины* использования JPA (Hiber, EclipseLink)?
Я согласен с тем, что правильно готовить Hiber, чтобы он летал и работал правильно, не так просто, нужно изучать книги, сталкиваться с подводными камнями. Но и JDBC без тюнинга и без понимания механизмов БД тоже будет тормозить (если не использовать индексы или везде лепить join) или будет ненадежным решением (например, если не использовать или неправильно использовать транзакции).
Поэтому правильно приготовленный Hiber не так уж сильно будет отставать от JDBC, но выигрывать в удобстве сопровождения кода (т.е. кода писать и поддерживать придется меньше чем на jdbc, и велосипедов будет меньше чем придется их писать на jdbc, т.к. у хибера (плюс спринг конечно) многое из коробки) при масштабировании кодовой базы, когда эталонные решения с хибером на проекте уже проработаны.
Здравствуйте, gyraboo, Вы писали:
G>Поэтому правильно приготовленный Hiber не так уж сильно будет отставать от JDBC, но выигрывать в удобстве сопровождения кода
Я видел много неудачных примеров использования хибера, и мало — удачных. Причем удачные — поголовно с компактной кодовой базой и низкой нагрузкой. Причем, по моему опыту, сопровождение кода — это главнейшая проблема хибернейта, т.к. изменение маппингов один-ко-многим, ленивость и флаши могут легко сломать код или привести к неоптимальным запросам в базу.
Здравствуйте, scf, Вы писали:
G>>Поэтому правильно приготовленный Hiber не так уж сильно будет отставать от JDBC, но выигрывать в удобстве сопровождения кода
scf>Я видел много неудачных примеров использования хибера, и мало — удачных. Причем удачные — поголовно с компактной кодовой базой и низкой нагрузкой. Причем, по моему опыту, сопровождение кода — это главнейшая проблема хибернейта, т.к. изменение маппингов один-ко-многим, ленивость и флаши могут легко сломать код или привести к неоптимальным запросам в базу.
Если у разрабов нет экспертизы видеть такие проблемы и уметь их решать, имхо голый JDBC их не сильно спасёт.
Здравствуйте, Sinclair, Вы писали:
S>Мне нужно освоить современный уровень ORM под JVM. S>Я так понял, что промышленным стандартом является Hibernate (если не прав — поправьте).
Hibernate + http://www.querydsl.com/ — всё по туториалам можно просто начать использовать.