Целесообразность использования Hibernate, Spring MVC

чем плох jdbc, зачем hibernate?

В небольшом приложении hibernate особых преимуществ не даст, jdbc будет вполне достаточно. Спринг по желанию, по мне так спринг это хорошо везде.

А вот если приложение в планах будет активно расти и развиваться, вот тогда ORM не помешает с самого начала.

расти будет 100% и объемы данных будут значительные с самого начала

Тут дело не в объемах, orm сильно упрощает разработку при наличии сложных вложенных объектов / множества связей между таблицами. Просто достать из бд пару сотен тысяч записей jdbc даже наверное быстрее справиться. Но например писать корпоративный портал на нем одному это реальная жесть, в конце изобретешь свой хибернейт, только хуже.

Особенно Spring JDBCTemplate

http://skinny-framework.org

в конце изобретешь свой хибернейт, только хуже.

спорное утверждение, хуже хибера и прочих JPA-like поделок сделать сложно

Я как-то участвовал в одном мегапроекте с JPA/Hibernate/Spring/Java 8 и всеми делами. Там понадобилось прикрутить отдельное веб-приложение для работы с богомерзким КриптоПро - он умел только Java 1.6, - а конфигурация этого приложения осуществлялась через БД. То есть приложение на JPA/Spring/Java 8 туда писало, а приложение на Java 1.6 оттуда читало. Так вот автор даже не стал заморачиваться чтобы к этому второму приложению тоже прикрутить JPA, хотя это было бы элементарно, учитывая, что это приложение жило в том же дереве исходников. Просто поскольку структура этого конфига была простой, легче было чтение сделать тупо через JDBC и ручками распихать полученные данные по соответствующим java-объектам, чем делать мэппинг, DAO, сервисы и прочую архитектурную мастурбацию.

Посмотри вот это http://zsoltherpai.github.io/fluent-jdbc/

в конце изобретешь свой хибернейт, только хуже

Чем хуже, что там в этом хибернейт за рокетсайнс? Как раз для Java очень не хватает полу-orm.

На одной стороне есть проекты типа sql2o или fluent-jdbc, но в них не хватает загрузки графа объектов и обновления схемы БД. На другой стороне слон в виде Hibernate, который делает кучу всего не нужного и сложен в конфигурации.

для Java очень не хватает полу-orm

jooq, ебатис

в них не хватает загрузки графа объектов и обновления схемы БД

Обновление схемы никакой орм для джавы не делает, это задача для отдельных тулов - liquibase и flyway

чем плох jdbc

Тем что он сделан для инопланетян, как HttpUrlConnection. Многие юзают хибер только чтобы кишки jdbc не видеть. Без надстроек вроде Spring jdbc template оно едва юзабельно.

Там понадобилось прикрутить отдельное веб-приложение для работы с богомерзким КриптоПро - он умел только Java 1.6

Ахаха, долбаное крипто-зло всё не меняется. Я по итогу работы с ним понял, что нормально с ним можно работать, только если его изолировать на отдельную JVM.

Обновление схемы никакой орм для джавы не делает

Hibernate делает, не всё, но многое.

jooq

Странный подход отказываться от доменов генерируя какой-то непонятный код из таблиц БД. Хотя может я и не разобрался и можно свои классы-домены маппить на БД?

ебатис

Как-то не увидел получение графа объектов. В примере на всех полях простейшие типы и никаких ссылок на другие домены: https://github.com/mybatis/jpetstore-6/blob/master/src/main/java/org/mybatis/... Да и каким-то легаси из нулевых потягивает.

это задача для отдельных тулов - liquibase и flyway

Они покажут diff между v1 и v2 схемой БД?

Hibernate делает, не всё, но многое.

Он только может сгенерировать DDL по Java-маппингу, и иногда корректно обновить. Из-за этого «иногда» эту фичу никто в здравом уме на проде не юзает.

Хотя может я и не разобрался и можно свои классы-домены маппить на БД?

Можно, я его только ради этого и использовал. Генерацию юзал только для типизированных запросов.

Они покажут diff между v1 и v2 схемой БД?

В каком смысле? flyway умеет только накатывать SQL-скрипты обновления версий. liquibase сильно больше умеет, но в первом приближении тоже просто ведёт и накатывает обновления.

Как-то не увидел получение графа объектов.

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

jOOQ currently doesn't support more complex data structures, the way Hibernate/JPA attempt to map relational data onto POJOs.

Так и этот не умеет в графы объектов http://www.jooq.org/doc/3.8/manual/sql-execution/fetching/pojos/ - вот документация, так же не удалось найти примеры с загрузкой графа. Только один объект, но это и fluent-jdbc или sql2o умеет.

Из-за этого «иногда» эту фичу никто в здравом уме на проде не юзает.

Само-собой у заказчика на проде я бы это наверное не юзал ) Хотя на своих проектах такой подход работал на проде без глюков )

В каком смысле?

Например, у меня есть схема БД построенная для ПО версии 1.0, скажем сгенереная тем же Hibernate. Дальше у нас появилось ПО версии 2.0 и в нём измененная схема БД. Так вот имея схему БД 1.0 и БД 2.0 было бы здорово получить патч в виде SQL команд, чтобы накатить на рабочую БД 1.0 и получить схему БД версии 2.0

Есть такие инструменты? Я как-то не сталкивался с таким, когда под себя сайты пилил. А сейчас вот десктопное ПО пишу с БД и надо туда патчи накатывать с новой схемой БД.

Хотя на своих проектах такой подход работал на проде без глюков )

Миграции это не только «добавить колонку», у колонок ещё бывают значения со своей семантикой. Hibernate может добавить что-то, но элементарную вещь вроде «создать колонку, набить данными, сделать not null» - уже нет. Поэтому в случаях, когда данные важны, я бы эту систему с самообновлением схемы не стал бы использовать. Да и я, если честно, не слышал и не видел, чтобы кто-то использовал. Всегда миграции это осязаемая вещь, которая может быть верифицирована DBA.

Так вот имея схему БД 1.0 и БД 2.0 было бы здорово получить патч в виде SQL команд, чтобы накатить на рабочую БД 1.0 и получить схему БД версии 2.0

Не уверен, что это хорошая идея, но, кажется, liquibase это умеет: http://www.liquibase.org/documentation/diff.html