Petro123А до jpa 3 года назад как писали?Я опять суть вопроса не уловил. JPA - это 2006 год, за 13 лет оно особо лучше не стало, даже наоборот: ну подкрутили что-то для восьмерки (хехе 21837183 ), а вот то что движняку NoSQL уже лет десять мы скромно умалчиваем (а JDO похоронили, ага)

Petro123ОРМ плохой и мы пишем самописки - еще глупее. Один уже признался.Я такого не писал (вам как бы уже намекнули в 21852547 ). Если нужно быстро запустить проект с кучей форм, то хиберуОРМ здесь не будет равных, проблемы возникают немного позже (ну там заказчик прочухает, что данных у него будет на пару порядков больше чем на старте, еще интеграции какие-то возникнут)

Petro123API Hibernate без спринга применяется.никто не отрицает, только вот тонкости в деталях, без спринга хибер умеет только JTA (тот же кот не умеет JTA из коробки) + страдайте с try/catch/finally
Petro123И почему скорость упадет при доступе по PK?ну вот опять... вы сначала говорите "в трехзвенке слои должны быть четко разграничены", а потом строите структуру СУБД по принципу "ну вот здесь наверное хиберу будет збс" - противоречия не находите?

Petro1231. Давайте пока... В первом чтении... Без тонкостей.
- ближе к jdbc API hiber. Пусть ТС говорит почему он не слушает прогеров и архитектора.Правильно делает что не слушает, прогеры у него индусы, если они что-то не знают, то будут всем утверждать что "это невозможно", "полохо" и пр. - тупо такой менталитет (при этом им платится рейт, который вам и не снился)
Petro1232. Вы сказали выше что хиберу будет плохо? Обоснуйте.Я почитал что примерно делается при закрытии опердня - там куча оперативных данных за день поднимается и меняется:
- во-первых, это явно должно происходить не через прямой через http-запрос (кнопку нажал, оно крутится через несколько часов получил результат), а через асинхронные механизмы (где-то атрибут выставил, оно потом джобой подхватилось - какой-нибудь @Async здесь плохо подходит, потому что я бы подобные вещи (пользаков и массовую обработку данных) вообще по разным серверам разносил), т.е. в хибере остается только сохранение формы в базе
- во-вторых, с масштабируемостью возникнут проблемы - ну вот базовая концепция "одна транзакция на поток" выглядит довольно удобно для формошлепов, но она не про производительность - если захотим пойти в многопоточность то придется постараться (здесь начнет всякая инфраструктура хиберовская мешаться)
- в-третьих, поднимать в память все подряд при массовой обработке - идея так себе (мы где-то замеряли: вставка через хибер была в 5 раз медленнее JDBC), если все делать через UPDATE то разницы с голым JDBC в плане удобства и "стройности" архитектуры не будет
- в-четвертых, с реализацией блокировок в хибере вообще все печально
- в-пятых, там задействованы внешние системы, поэтому без правильного планирования транзакций (ну или логов) не обойтись - тоже не конек хибера

Petro123Вы умудрились в 4 раз не ответить на вопрос. Где будет метод?
Не понравился метод? Выше был второй

Я могу вам в 4-й раз ответить, что в ОРМ его не будет никогда, просто потому что, когда имеем дело с бабками, то я хочу увидеть в базе ровно то что я написал, а не то что бракоделы из редхата решили записать, потому что у них видите ли не получается достоверно определить что нужно сбрасывать в базу, а что нет. Будет это лапша на JDBC или хранимая процедура - мне все равно, у кого в конкретный момент времени будет свободное время, тот и сделает.

Petro123я и не говорил про ОРМ.
Давайте угадывать.
- в сервисном слое?Вам сколько раз нужно написать, что принципиальной разницы между "select ..." и "{call ..}" нет?

Petro123у вас прогер решает, хранимку напишет или метод java?Человек с техническим образованием, не техпис, не PM и не QA.