Максим Федоров, Суть в том, что join в запросе будет, а вот связанных сущностей не будет.
Т.к. Java типизированный ЯП, а Hiberntae это ORM. То результат запроса должен быть строго типизированным, в не зависимости от того сколько связанных таблиц принимало участие в запросе.
Так что join есть, но результирующая выборка будет того типа который указа в HQL после "select"
Павел, Да. Правильно. Вот только передавать сущности в сервисы, как бы моветон. Нужно преобразовывать через DTO в бизнес объекты.
Ну как бы так "правильнее"
Максим Федоров, Не знаю как в PHP, но JPA CriteriaAPI это очень не удобная вещь.
Пользоваться ей можно только от безысходности.
А так, если нужны "гибкие" запросы, то можно писать запросы на SQL и мапить их на сущности.
В рамках Hibernate.
Опять же проблема N+1 это проклятье почти всех ORM.
Написать, который работает не только на вашем компьютере. ;-)
Смотрите отличие в окружениях.
Скорее всего контекст вашего компьютера отличается от контекста CI окружения
Виталий Столяров, В продолжительной - тем более лучше "разделять".
Т.е. оптимальнее всего создать общую библиотеку, на основе которой делать сайты.
Чем пытаться сделать универсального монстра.
Скажем так у меня был опыт написания двух "одинаковых" порталов.
По мере "уточнения ТЗ", оказалось, что они нифига не одинаковые.
Хотя никто вам не мешает самому пройтись по граблям. :-)
ximzavivka, Если вы хотите работать со SpringBoot, то фронт-енд у вас будет SPA(single page appliocation), например на vue.js. А SpringBoot будет предоставлять REST-API. Просто почитайте что такое SPA и REST-API.
Алексей,
Правильно, а вы что хотели?!
ИМХО использование БД в контейнерах, не самое удачное решение.
Хотя как вариант для разработчика вполне себе удобно.
Т.к. Java типизированный ЯП, а Hiberntae это ORM. То результат запроса должен быть строго типизированным, в не зависимости от того сколько связанных таблиц принимало участие в запросе.
Так что join есть, но результирующая выборка будет того типа который указа в HQL после "select"