andreykaTнедавно с товарищем говорил, он описал ситуацию что в сложных запросах хибер не поможет и в любом случае будет скуль. Я вот думаю.. что за такие запросы, которые на хибере реализовать не выдйет?
орм - это кэш плюс генератор запросов плюс возможность писать нативный sql
оно не умеет из коробки специфичные штуки типа обработки иерерхий, конкатенации записей в одну строку через запятую, проблемы провайдеров, когда надо сортировку, фильтр по алиасам и пейджнг одновременно, нельзя использовать хинты

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

а еще генератор запросов делает не оптимальные запросы

поэтому подход следующий - для выборки данных - нативный sql, для CUD операций - ори

maytonДобавлю что миграция с одного SQL на другой - это какая-то мифическая постановка.
в моем случае была не миграция, а поддержка двух субд, проект в банковской сфере, большинство банков использовало оракл, но в некоторых был mssql

кстати гибернейт справился на отлично, я дописал кастомные типы данных для xml и заменил строку подключения, но пришлось нативный sql выводить в хранимки с одинаковыми именами и параметрами, сделать кое какую обвязку и в итоге я получил независимость на уровне доступа к данным в приложении

правда потом был гемор с поддержкой хранимок :)

mayton,

не помню такого, возможно изза того, что я вывел управление транзакциями в слой доступа данных в связке с DI/IOC контейнером, чтоб можно было атрибутом пометить бизнес метод, что он должен выполнятся в транзакции - когда бизнес метод завершает выполнение - приложение просит базу закомитить транзакцию

так же оно умело вложенные транзакции