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 .......");
Я надеюсь вы не приемлете декларативное управление транзакциями и всегда стартуете / стопаете вручную ;)

Andrephilosподход что я предлагаю обясняется за час.
Не верю, что вы за час сможете научить юниора КАК развернуть и самостоятельно настроить ваш ORM. В смысле как ваши классы инструментализации встроить в другое приложение.

AndrephilosОбучение хибернейт долго и нудно, ведь почему то в открытых вакансиях сильно важным критерием есть опыт хибернейт значит не так быстро его понять.Это шедеврально =)))
почему то в открытых вакансиях сильно важным критерием есть опыт хибернейт СЛЕДОВАТЕЛЬНО не так быстро его понять СЛЕДОВАТЕЛЬНО Обучение хибернейт долго и нудно.

Его стоит изучить как и другие технологии. JPA ничем не лучше чем JMS или EJB. Каждая нужна для своего круга задач.

Объясню почему я бы стал вписывать Hibernate в вакансии - я считаю, что JavaEE разработчик не знающий Hibernate это максимум junior и может претендовать только на соответствующую зарплату. Пока не сможет изучить все базовые технологии. Может еще для Java EE стоит не изучать EJB, JMS, JSF и прочие базовые для EE технологии.

AndrephilosVoDA

id=Integer.valueOf(mae.get("fleld_id")).intValue(); Это шедевр. Как только напишите 30-40 сущьностей с применением этого подхода, так сразу проявится DAO / фабрики / Util классы ;)
Здесь замечания не понимаю.
А хотелось бы ...Скажем так - каждая строка сложнее return id; это затраты на поддержку. Даже написать javadoc + прогнать unit-тесты + по мелочи. Чем меньше кода в моем приложении на java (это важно) при той же функциональности, тем меньше себестоимость, а значит выгоднее мое приложение для заказчика.

PS найди ошибку в коде выделенном мной. Он скомпилится, но работать откажется :)

HauerЧто касается перехода на другую СУБД - это все от лукавого, мне кажется. Никто этого практически никогда не делает. Другое дело, если у вас "продукт", который может работать с несколькими СУБД по выбору.Зависит от сферы - в аутсорсе переход с одной СУБД на другую это практически штатная функция приложения. бОльшинство проектов в которых я работал работали минимум с 2-я СУБД, а чаще 3 и более.

AndrephilosЯ работаю только с вебом соответственно говорю только о веб. Просто не понимаю моду, где надо и где не надо тычут хибернейтДля веба вообще java - overhead. Применяйте PHP

Andrephilosне верите потому что опираетесь на опыт обяснения хибернейт :)
Ага, я переучил несколько человек с С++ на Java/JavaEE. Плюс один из первых java проектов был на самопальном JDBC-лисапеде для работы с СУБД. Тормозило дико, а переписать было дорого, потому начальство очень долго ... думал о выделении команды под эту задачу. В итоге заказчики отказались раньше, чем этот JDBC-велосипед переписан.

С тех пор я очень критически отношусь к попыткам заменить готовые фреймворки на самодельные. Цена поддержки самоделного лисапеда полностью ложится на компанию - часто это экономически не выгодно.

AndrephilosТеоритечиское знакомсвто и практический реальный опыт разные вещи. Все технологии опробовать на реальных проектах жизни не хватит (грубо говоря)Базовых технологий в JavaEE не так уж и много (около десятка). Если не глубоко копать, то по технологии в несколько дней хотя бы почитать. Это junior. Как только они будут проверены хотя бы в тестовых приложениях, тогда можно говорить о java developer. Написать 4-5 тестовых приложений - я не считаю это серьезной задачей для человека, который утверждает, что он java developer. Для Senoir нужен опыт практического применения оных технологий. Обычно в проекте на JavaEE они все используются - посидеть и вникнуть + покодить самому.

AndrephilosИ почему вы выбрали именно эти технологии?только потому что вы с ними знакомы вы их называете фундаменталным :) ? Если вам доверят провести собеседование и брать кого то на роботу, тоже по этим критериям будете судить о будущем гуру :) ?Выбрал эти ибо они входят в JavaEE, а значит разработчик на Java EE (выделю эти буковки еще раз) должен ими владеть. Мое знакомство с теми или иными технологиями дело ортогональное собеседованию - мне важно чтобы человек был адекватный, а там научим ;)

Будущий гуру - это классный титул, только нужно доказать. Не знания доказательством не являются.

Andrephilosот EJB пытаются отказываться в мире.
JSF - далеко не фундментальная а просто на любителя как и Spring MVC, flow, struts,...А вы много замен EJB знаете? ;)
JSF тема тонкая - я не специалист по реализациям JSF. Но могу сказать, что критиковать технологию может только тот, кто ей владеет на уровне senior или гуру. Вы владеете JSF на уровне senior или просто почитали критику на новостных сайтах?

AndrephilosЗдесь вы недооценивает PHP программистов, я б даже сказал неуважительно относитесь.
Лично я PHP не использую, не хочу и не советую, но имею реальный опыт конкуренции с ними и именно поэтому большинство сайтов в мире написаны на PHP, потому что умники что програмирую на JAVA усложняют себе и другим жизнь используя ненужный сложные для изучения технологии.Ага то то facebook не смотря на то, что написан на PHP движок для хранения данных в нереляционном виде написал на java. Наверное это заговор =)))

ИМХО сайты на PHP пишутся сначала потому что порог вхождения ниже и быстрее изучается, а потом потому как переписать на другой язык - дорого и нужно тратить время. Уже проще допиливать PHP.

Andrephilosесть аргументы в защиту Хибернейт или наоборот.

Или написать для каких задач лучше использовать хибернейт, а для каких не стоит.Хибернейт стоит применять когда схема БД стабильна, когда схема может меняться при работе приложения Хибер противопоказан - слишком сложно и геморрно будет.