ЕлдосИмеет ли смысл использовать hibernate или spring когда есть встроенный в томкате средство для БД?
что будет быстрее работать, важна скорость и безопасность
Имеет ли смысл купить жигули, или лучше на тележке кирпичи возить, если у меня в розетке дома 220В. Важно чтобы сила тока была постоянной.

В Tomcat нет встроеных средств для работы с БД.
Есть встроеное в JSE API средство, которое называется JDBC.
Hibernate это ORM, который решает свой класс задачь.
Spring это вообще контейнер состоящий из десятков модулей. О чем конкретно речь не понятно.
Скорость и безопасность вам не важна, пока вы не разбираетесь даже в предназначении различных API и собираете SQL параметры через конкатенацию.

Елдосда, я не понимаю я еще учусь, и объяснить сложно было.
подскажите что что мне использовать, задача чтобы в час может в день 100 000 запросов в БД.
что посоветуете использовать?
Производительность это фиговый критерий выбора фреймверка.
Основные критерии это
1) Упрощение кода, замена рутины фреймверком, высокая читаемость.
2) Массштабируемость. Даже если ваш сервер будет выдавать 50 000 запросов в час максимум. При хорошей масштабируемости вы тупо подымете второй такой сервер. И решите проблему роста. А если у вас сервер вадёт нужные 100 000, а завтра нужно 200 000 и он не масштабируется, это на много хуже.

Объясните проект. Подберем фреймверк.
Spring Data + JPA - умеет прятать куча рутины. Но вам бы я его не рекомендовал вообще. Так как без понимания как оно работает внутри будет очень не просто.
Hibernate/JPA - это обычные ORM. Они полезны когда у вас много CRUD и сущности связаны в крупные деревья ассоциаций (человек-работник-должность-департамент-подразделение и т.п.)
myBatis - никогда не пробовал, но народ почему-то хвалит. Меня отталкивает кучей рукописного SQL. Возможно решает вопрос с ассоциациями?
QueryDSL, JOOQ и другие аналоги. Довольно приятные SQL билдеры. Не решают проблемы ассоциаций, но решают вопросы динамического SQL и использования SQL в проекте. JOOQ, вроде, платный для комерческий проектов.

А вопросы безопасности и скорости ни один фреймверк за вас не решит.

t00kukЕсть у меня ощущение, что всякие ОРМ, Майбатисы и жуки - они для тех, кто не может в SQL.
Согласен. ВАЗ 2101 - вещь. Все эти ваши "тойоты" и "форды" для тех кто не может коробку пересобрать. Рассуждения на уровне гаражного механика.
Разные инструменты решают разные задачи. Кичится своим невежеством не прилично. myBatis так вообще один сплошной SQL.

J2ee DeveloperЗря, зря.. MyBatis - рулит!!! Лично мне не влом писать вручную insert'ы и update'ы, если я при этом на 100% понимаю, как это работает.
По мне JPA слишком сложен, и не облегчает жизнь программиста, а наоборот, её усложняет, до предела запутывая доменную модель, сложными ассоциациями. В то время как в MyBatis ты мапишь сам запрос на тот или иной домен.
А мне было бы вром писать 100500 CRUD запросов для нескольких сотен сущностей. MyBatis, веротяно, рулит как инструмент интеграции Java/SQL. Но не решает кучу вопросов, которых хотелось бы отдать на уровень фреймверка.

J2ee DeveloperПлюс, как правило в команде, не все разработчики являются гуру, а есть и junior'ы и middle'ы. По моему опыту даже многие senior'ы не до конца понимают, как работает jpa.

No Comments по поводу такие "синьёров". Но, в целом, правда. Hibernate стал достаточно сложным инструментом с массой спефицичных фишек и подводных камней. А зоопарк JPA провайдеров делает всё только хуже.

J2ee DeveloperПро быстродействие вообще молчу. Сложные селекты, так вообще просто ад.

Какое отношение селекты имеют к производительности? Использовать SQL в сложных местах достаточно не сложно.
А вот как решаются вопросы генерации динамических SQL в myBatis, было бы интересно узнать.

J2ee DeveloperМое мнение, что JPA имеет смысл использовать только, когда нужна поддержка большого кол-ва разных СУБД, ну или для какой-нить админки, где производительность не критична, а нужен тупо CRUD.
На счет поддержки разных СУБД это заблуждение. Портирование проета под другого SQL вендора это всегда большая задача вне зависимости от использования ORM.
А вот на счет CRUD - верно. Это то самое в чем ORM подруливает очень сильно и кешами, и персистентными коллекциями, и dirty-check апдейтами.

J2ee DeveloperПоймите правильно, а не отрицаю того факта, что и на MyBatis можно заговнокодить так, что оптимизированный JPA будет на порядок быстрее. Я лишь говорю свое впечатление об этом framework.
Каждой задаче свой фреймверк. Но спорить сложно, с тем фактом что ORM далеко не все вопросы закрывает, даже если это такой продвинутый инструмент как Hibernate.

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

MasterZivПри этом, я хочу заметить, проблемы масштабируемости самой БД (сервера БД) никаким фреймворком никак не решается.
Hibernate с простой возможностью подключение распределенного кеша второго уровня, как раз что-то решает. Просто умиляют пожелания "мне надо быстро и секурно" в комбинации с конкатенацией параметров SQL в строку.

Nixic


А Lazy здесь точно работает? Ведь, без дополнительной инструментации\проксировании кода, Hibernate не сможет сделать свойство ленивым.

Nixicи если мне надо получить какой-то объект который связан с Product я просто вытаскиваю его по productId а не через
product
Если ассоциация ленивая, то в product.id будет FK из текущей таблицы. И его чтение не приведет к запросу в product. Поэтому заводить дополнительное поле смысла нет.

NixicВроде как стало меньше тормозить, но! правильно ли такое решение. Я вообще особенно глубоко не изучал hibernate. Все решаю тогда, когда возникает текущая потребность.
Решение странное и на правильное не похоже. Для динамического управления ленивой ассоциацией fetch можно передать в запрос HQL или в Criteria API. Чтобы загрузить Product одним JOIN запросом. Что в вашем подходе невозможно. Вы сделали lazy ассоциацию чтобы ей никогда не пользоваться?

В, целом, идея здравая и имеет право на жизнь, но в каком-то другом ORM. Не в Hibernate.