VadyaУважаемые знатоки Java!

Сам я не Java-разработчик,поэтому извиняюсь,если будут некорректные мысли у меня по этому поводу.

Скажите мне,в чем ценность использования Hibernate?-упрощение процесса разработки и т.д.?

Насколько я понял,Java напрямую не пишет SQL запросы,
а их генерит Hibernate. А так происходит маппинг между объектами и таблицами.
Так вот ,я счиатю это полная херня(если я правильно понял),что
разработчик не пишет SQL-запросы и сидит,как слепой котенок - что же там HIbernate пишет в базу?Я понимаю,что можно отмониторить SQL-запросы.
В любом случае разработчки напишет SQL- запрос более оптимизированный ,чем HIBERnate.
Буду очень рад,если развеете мой пессимизм.
(если я вообще правильно понимаю HIBERNATE)

Ну в целом вы правильно понимаете задачу Hibernate
Только вот выводы несколько того...
Hibernate ценен тем, собственно не только он а и любая библиотека ORM, что избавляет программиста от кучи рутины типа беганья по ResultSet'ам и обработки тучи исключений при работе с БД, даёт переносимость между БД, предоставляет удобное API, в том числе и API для native - запросов. Конечно Entity Beans занимаются собственно тем же, но Hibernate более гибок и прост в применении, кроме того сфера его применения не ограничивается App Server'ом.


А по вашему получается, что и Application Server это зло не меряное, что это такое сам управляет пулами соеденений, сам управляет пулами компонентов, херня какая. Да и Java тоже не лучше! Где управление памятью как в С? А то что эти вещи иногда в разы увеличивают скорость разработки и её качество? Можно написать распределённые компоненты "с нуля" не используя Application Server, придумать свой протокол передачи, свою библиотеку работы с БД, потом когда понядобится работа в кластере дописать и её, потом при переходе на другую платформу, адаптировать, потом потребуется обеспечить доступ к компонентам с других платформ, о5 писать и отлаживать и тд, и тп. Тоже можно и базой данных, яж не знаю как она там внутре с моими запросами себя ведёт, нафиг , базу тоже "с нуля". Но закончится ли такой проект хоть в когда-нибудь, хоть чем-нибудь вразумительным? Не знаю.

------------- Vadya
наши Java почему-то целый день отлавливали ошибку,причина которой был
констрэйнт not null. То есть оин пытались вставить Null в столбец,который not null.
На вопрос:что за SQL-запрос,мне в ответ.хрен знает - его HIBERNATE генерит.
Скорее всего это они тупят.

Воистину тупят - в Hibernate есть настраиваемый logging , да и DB можно заставить журнарировать SQL.
Ну и кроме того при описании поля в Hibernate можно указать что оно not null :)

am_sasaЯ тоже не использую хибер, поэтому хаить его не хочу. Вопрос скорее в следующем "Зачем нужен ORB". Я делал большой проект без него и все замечательно получилось... С моей точки зрения, зависимость программного кода от структуры БД - не есть хорошо!!!

Поэтому вопрос, какие признаки должны присутствовать,чтобы принять решение об испоьзовании хибера?
Что-то я не пойму единственные программы код которых не зависит от структуры БД, которые я могу себе представить, это программы не использующие БД. :)
Можно конечно прекрасно обходиться без ORM никтож не спорит с этим. И потом, что такое "большой проект"? Десктоп? Серверное приложение? Эти две вещи сильно между собой отличаются идеологически, а значит и подходами. В десктопном приложении вполне себе можно просто получить конект к БД и парсить результ сеты, в серверном на уровне EJB... ой вряд ли, будет абсолютно не масштабируемо. То есть встаёт выбор либо стандартные Entity Bean, либо какой-нить ORM. О5 же вопросы переносимости. SQL хоть и стандард, но реализации от разных производителей серьёзно отличаются. Hibernate позволяет сделать переносимое преложение. Ну и потом повторюсь ещё раз, у Hibernate удобный API. Именно програмный API, в принцепе вполне возможно написать приложение без строчки кода на SQL или HQL. Это удобно, когда запрос нужно конструировать в зависимости от каких то условий. Да и просто по моим личным ощущения быстрее получается в плане скорости разработки.

AndreySerjНесмотря на все плюсы Hibernate, позвольте спросить: А часто ли Ваш проект, особенно большой проект, требует переноса между БД. Как правило, такое случается очень редко, а для БОЛЬШОГО проекта еще реже.
Согласен. В условиях проекта под конкретного заказчика такая вероятность практически равно 0. В случае проекта не привязаного к конкретному заказчику такая ситуация вполне вероятна. Во всяком случие минусом системы это никак не станет.

am_sasa Timm
т.е. ты хочешь сказать, что твой программный код использует бд, но при этом не зависит от ее структуры? :-) забавно, для чего тебе тогда бд? выполнять запросы вида
? аха))) вопрос как реализовать логику не имея в памяти объекты реализующие структуру БД - это отдельная тема, вполне решаемая...
зато, при дороботке структуры БД, переписываются SQL запросы и,если потребуются, маленькие кусочки кода!
Ну в случае с Hibernate придётся доработать только описание нового поля а его обработку придётся дорабатывать и в том и в другом случае. Так что никакого выигрыша не вижу. По поводу "не имея в памяти объекты реализующие структуру" я так полагаю вы очень лукавите. Знать структуру данных с которыми работаешь и иметь их представление на уровне объектов это единственный возможный путь. Вы можете конечно хранить полученные наборы записей в массивах или скажем векторах, но сути это не меняет, в любом случае хранить их надо и знать что ты храниш тоже, иначе как потом обрабатывать, кроме того вы сознательно добавляете себе не нужный геморой по парсингу результ сетов в какие то коллекции, не говоря уж о том, что в коллекциях данные безликие, доступ только по индексу и надо всегда помнить, что вот в 3й позиции у меня лицевой счёт а в 10й сумма. Вообщем гимор редкий.