а можно подробнее, почему?
конкретные примеры, если возможно.

не верю. аргументы в студию!

Asal, 
dEEp, 

Свое мнение и доводы против JSF я высказал в этой теме:
http://forum.vingrad.ru/forum/topic-213156...tml#st_0_view_0

ok.

О каких конкретно запросах идет речь? На получение/изменение данных? Так их всегда самому можно написать в Hibernate. Если это DDL запросы на создание таблиц БД, то, впринципе, проектировать от БД к объектам никто не запрещает. 

P.S.: Теме когда лучше использовать ORM фреймворки, а когда голый SQL посвящена одна из глав книги Мартина Фаулера "Архитектура корпоративных программных приложений". Там достаточно подробно описаны плюсы и минусы технологий в зависимости от сложности проекта.

только на получение данных.
изменения данных я описываю хранимыми процедурами на уровне БД.
про DDL и речи быть не может, это этап проектирования, а не работы приложения.


минус один и большой - это потеря производительности на БД сервере.
плюс для разработчиков которые не владеют СУБД и не хотят вникать в особенности его работы на базе которой ведется разработка ПО. как несложно догадаться этот плюс чаще всего приводит к необратимым последствиям.

и снова вопрос: имеет ли смысл использовать ORM фреймворки в моем случае?
мне просто хочется понять какое приемущество я получу используя их, а не голый jdbc.

так тогда не понятно какой ваш случай? у ТС это небольшая соц. сеть а у вас то что? 

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

хотя мне кажется опять же что проще сделать на хибернейте и купить мощнее сервер - дешевле будет 

в минусах от jdbc - долгая разработка + зависимость от БД

ЗЫ а так действительно лучше Фаулера почитать )

поверьте, нет систем которые не зависят от СУБД, невозможно без переработки кода просто взять и перенести ПО на другое СУБД.


и что Фаулер советует поступать именно так?!

Но для этого не надо километры кода менять.
Не понравилась MySQL пожалуйста, поменяй одну строчку в persistence.xml и используй другую БД.
Не хочешь Hibernate + MySQL, а хочешь Oracl + TopLink, поменяй 5 строчек.
Но это если работать с JPA.

P.S. ИМХО

я не спорю что после изменения этой строки ваше приложение сможет работать с другой БД, но вряд ли бизнес процессы которые изначально были определены будут работать так же.
простой пример:
есть таблица в БД с названием test
она содержит след. поля и значения:
поле: name
значения: 1, 2, 3, null

некое ПО было написано под БД MS SQL. кончепцией этого ПО является - "не показывать данные с пустыми значениями".
програмист выполнил задачу написав такой запрос:


после миграции системы на оракл главная концепция ПО перестала работать т.к. данное условие "name <> null" в оракл возвращает false- следовательно пользователь перестал вобще получать данные.
и только переписав запрос таким образом:

мы получим необходимый результат.



Asal, это верно! действительно ПО будет работать с новой БД, но как?!
так что любой кто утверждает что он написал ПО которое может работать под все БД(без переписывания кода), говорит это только по тому что он не пробывал его мигрировать на другую БД.

Это сообщение отредактировал(а) DimW - 24.9.2008, 11:08

социальная сеть это задача которую нужно решить, а не подход к разработки. 
так что не понятно?


для меня вопрос не стоит хочется или нет. я именно так и поступаю.

так едрен-батом, кто нибудь ответит мне на мой поставленный вопрос - как в моем случае мне помогут ORM фреймворки?

Это сообщение отредактировал(а) DimW - 24.9.2008, 11:26

мне кажется только переносимостью спасают. 

я никогда не отказывался от jdbc и отказываться не собираюсь.

dEEp, мне тоже кажется что это один из весомых аргументов на который "ведутся", но хочеться услышать остальные доводы.

Это сообщение отредактировал(а) DimW - 24.9.2008, 14:46

А что у вас за случай? А то, кроме максимизации производительности взаимодействия с СУБД, других требований нет? С таким единственным критерием то конечно, - JDBC лучше.   

DimW, во-первых это было мое ИМХО.
во-вторых есть такая штука как

разве оно не за это отвечает ?

а я этого не утверждаю