AndrephilosКто реально считает HIbernate нужной и полезной технологией?

Лично я использую JDBC (не чистый а несколько своих класов, аналог как в спринге)а какое отношение Hibernate / JDBC / JPA / ORM имеют к проектированию БД?

схема БД проектируется под хранение данных, а перечисленные технологии - способ доступа к данным. считаю, что флейм можно закрывать ввиду отсутствия вопроса. Проектирование БД не зависит от способа доступа - ORM это будет JDBC или ADO, ODBC... или unixODBC

AndrephilosНет не придется.Для роботи с БД достаточно создать для каждой сущности класс в котором есть методы:
добавить, извлечь, удалить, заменить + те которые нужны в конкретной задачи

Привемр select
Пример очень сильно похож на толстые-сущьности, которые и сами себя умеют сохранять. Мне ближе подходи DAO, а не fat-entities.

Дальше в вашем примере есть несколько косяков и лисапедов:
public static List<MyEntity> getListInstance() сделан статиком, значит MyDBconnnect является также статическим объектом, а вероятнее всего (из названия) это целый класс. Это проблема если приложение вдруг потребует НЕСКОЛЬКО соединений с БД.
Как вы к этому будете подключать пул соединений - сами писать? еще один лисапед?

Дальше предполагаю, что основной косяк будет здесь: new MyEntity(list.get(i)) - для каждой сущности придется написать маппинг - зачем если есть готовые фреймворки? если нет желания изучать JPA / Hibernate - работать с iBatics.

AndrephilosИ этого достаточно. Это намного проще чем розбираться в дебрях Hibernate , а потом и в глюках.
Проще и дешевле чем обучать юниоров это хибернейту его настройкам и так далее...

Однозначно такой подход лучше для приложений аля интерент-магазин и меньше.
Интерисует коменты в каких случаях это плохой подход.Этого достаточно чтобы народ кодил с помощью этой системы, но сама система будет сложнее DAO с Hibernate - Hibernate уже оттестирован, опробован под нагрузкой и т.п. А в случае своего велосипеда все это придется повторить для вашего самопального ORM.

Юниоров не обучают настройке Hibernate, также как никто не будет учить настройке вашего ORM - всех будут учить только применять ORM.

Однозначно готовые ORM в том числе Hibernate лучше подхода с самопальными ORM-ками. Особенно если нет опыта применения ORM в 3-5 боевых проектах.

HauerЧто касается разных СУБД, то все-таки иногда что-то приходится менять при переходе в конфигурационных файлах Hibernate. Например, Oracle имеет sequence механизм, кто-то имеет identity, есть и другие тонкости.А AUTO не подходит для этого случая?

PS у нас чаще работала.

AndrephilosКуча стандартных пулов не использовать же из а пула Хибернейт.Переведи на русский ;)

AndrephilosДля МуEntity - нужно писать мапинг, но и в хибернейт надо.
для одного поля одна строка типа :
в Хибернейте НЕ нужно писать маппинг. Совсем. Достаточно только указать @Entity. Тип для преобразования используются из типа поля / геттера. И т.п.

id=Integer.valueOf(mae.get("field_id")).intValue(); Это шедевр. Как только напишите 30-40 сущьностей с применением этого подхода, так сразу проявится DAO / фабрики / Util классы ;)


PS я тоже не до конца принимают идеологию Hibernate - JDBC он проще для изучения, но увы для постоянной работы требует слишком много усилий - дешевле научить команду пользоваться Hibernate, чем постоянно дописывать велосипед-ORM.

AndrephilosДобавим два плюса в итоге имеем:
1) Возможность перенастройки на другую СУБД
2) кеш (уточните в каких случаях это плюс при каких нагрузках, напрмер при нагрузке один запрос к случайной страницы в минуту вряд ли это плюс)
3) lazy loading (тоже нужно уточнить для каких приложений это плюс а для каких и не надо)Для готовых ORM:
4) отказ от id=Integer.valueOf(mae.get("field_id")).intValue(); - проще жить и рефакторить.
5) применение готового функционала - не нужно тратить время разработчиков на дописывание своего ORM, тестирование, документирование и т.п.
6) Снижение стоимости разработки ввиду пункта 5 - дешевле показать как пользоваться Hibernate, чем постоянно вкладываться в п.5.

Кроме того преимущества самого Hibernate над JPA я уже указывал - их тоже стоит перечислить.

Andrephilos2) кеш (уточните в каких случаях это плюс при каких нагрузках, напрмер при нагрузке один запрос к случайной страницы в минуту вряд ли это плюс)Когда количество АппСерверов больше количества серверов СУБД.

Andrephilos List<Map> list =MyDBconnnect.select("select * from .......");
Я надеюсь вы не приемлете декларативное управление транзакциями и всегда стартуете / стопаете вручную ;)