Ух_ТыЛюблю дискуссии ...
Высоцкий песню написал - "я не люблю ..." у вас тоже есть все шансы
Ух_ТыИмеется (к примеру) серьезный корпоративный проект основанный на (скажем) 1000 табличек + 500-600 вьюшек. это значит, что проесктов было несколько, развивались они продолжительное время и связаны между собой. Стратегически верным было бы уменьшать связность между ними. Ничего страшного нет в хорошо спроектированной domain model таких размеров.
Ух_Ты Более того, есть особые нюансы при изменениях табличек (и также вьюх), зависящие от грантов пользователя, влажности воздуха и прочих погодных условий. А вот это уже "своя книжка в чужой мечети". Либо ваши domain model классы реализуют всю эту логику, а их результаты этих мегаобновлений выпуливаются хиберов в простые запросы. Либо вы сажаете на вашу корову (приложение со сложной логикой в БД) седло (Хибер) и говорите что седло - говно. Я тут даже спорить не буду - факт:"хибер г-но".
Ух_ТыДа, и неплохо было бы нормально отслеживать транзакции в этом приложении.
Я думаю чем чем но этим явистов не загнобить. (к сожалению к хиберу это отношения не имеет). как старые монструозные AppServ так и новомодные IoC контейнеры в транзакциях рулят и рвут всех и вся в совершенные клочья
Ух_ТыВопрос - Hibernate с этим справится?
Даже не так...Справится ли программист, которому суждено описать 1500 классов? Вам нужен кодер продвинутый в ООПе и в Хибере (обе составляющие оочень важны).
Ух_ТыИли я неправильно понимаю этот чудесный продукт? Вы ассимилируете его призмой имеющегося у вас опыта. Думаю по этому он вам не подойдёт. Вы рассматриваете его как объектную нашлёпку (как я понимаю, не вам нужную, а навязываемую) для вашего old-age приложения. Конечно путём кропотливого фака можно придумать и сконфигурить его, для чего-то подобного, но целесообразность этого как у пришивания рукава к ... Как правило рефакторинг old-age'а штука болезненная, и болезненно бессмысленная, лучше убить и родить заново или интегрировать с пом. разл. интерфейсов ... типа коннекторов

ИМХО: 1.Хибер имеет большие отличия от ОО СУБД, эта одна из проблем у новичков, которые воспринимают его как серебрянную пулю. Они думают: "ух ты, нах, обёкты персистятся сами ..." Потом оказывается, что не все, не совсем они, а удалить "ваще капец". Одно из таких отличий атрибут insert на ассоциациях - нужен для чего?? для того что бы не требовалось "понимать" SQL если не ясно о чём я - попробуйте без него. Это ограничение позволило сделать его простым и эффективным
2. в нём есть своеобразная коллекция "баянов" изучаются которые посредством ударения об стену собственной головой (пример- поищите на форуме хибера many-to-many remove inverse side - забавно). неплохо было бы гденибудь такую коллекцию собрать. Есть идеи??
3. И традиционное: "хибер нужен только для того что нужен и для другого он не нужен" а именно для мэйнстримного вёба. Понятно что его можно юзать как угодно и где угодно. Но у него есть изначальная область для которой он писался. (можете биографию кинга посмотреть). Ясен пень что в приложениии где например данные пишутся каким нибудь old-age'ем в real time'е, два роскошных уровня кэша тока мешают. ну и не надо там его юзать как и для рутинных bulk updateов. Зато хибер можно ахиренно кластеризовать и использовать там где его кэш действитеьно нужен .

всем пока

он подходит для сложных изменений большой модели. И там где запросы частенько попадают в кэш - типа "сущность-по-первичному-ключу". если вам нужно отображать результаты кишковыворачивающих SQL запросов (и кэшнуть их низя) то понятно что база которая эти запросы выполняет есть узкое место а хибер бесполезная нашлёпка. Но если туева хуча юзеров дыбает каталог из базы - то хинтов в кэш там будет много и если логика (хибер) работает там же где и представление (кто так не делает или имеет ооочень веские причины или не здоров), то хибер ну очень помогает - разница между первым запросом (к базе) и вторым (из кэша) просто огромна

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