| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > hibrnate |
| Автор: katala 15.5.2006, 18:52 |
| народ расскажите мне плиз какие преимущества и какие недостатки у технологии hibernate по сравнению с обычной работой с базами данных???? заранее огромное спасибо за ответ |
| Автор: Tony 16.5.2006, 15:54 |
| Так себе.чтобы исползовать в ком. проектах нужно знать от а-я. |
| Автор: ALKS 16.5.2006, 16:22 |
| достоинство основное в абстрогировании от специфики SQL cинтаксиса конкретного SQL сервера. есть естественно у другие приимущества но они вторичны. недостаткок первый, как правильно заметили - фреймворк нужно знать, нужно уметь пользоваться и конфигурить, нужно уметь обходить ограничения. т.е. это не так просто как pure java.sql недостаток второй произтекает из основного достоинства: ну во первых это не так быстро как доступ к базе напрямую (и даже пусть реч идет о милисекундах, но эти милисекунды вы теряете) ну и во-вторых, часто используя всякие труки предоставляемые специвическим синтаксисом конкретного SQL сервера можно добиться заметного эфекта, а тут вас в этом ограничивают... мое имхо - если вам не нужна поддержка мульти-баз, то и не надо вам оно. а если нужна - жизнь спасёт.  |
| Автор: tux 16.5.2006, 16:56 | ||
Еще два достоинства:
Это конечно, но ничто не мешает использовать hibernate и plain sql одновременно. В Hibernate даже есть специальный механизм для поддержки родных диалектов - native SQL queries. О недостатках уже сказали. Вообще главное (впрочем, как и для любого другого программного продукта) - разумное использование. Тогда Hibernate подойдет практически для любого проекта. Единственное, чего точно нельзя добиться - повышения производительности. |
| Автор: ALKS 16.5.2006, 17:25 |
| ну насчет сокращения объема кода.... смело можете добавлять размер кода самого hibernate который становиться частью вашего приложения. и размер конфигов - до кучи. насчет привычных классов и атрибутов... вот я например вырос как программер из приложения для баз данных. для меня оперировать языком структурированых запросов при работе с реляционными БД до сих пор кажется намного более естественным, чем классами и объектами... но. я согласен что если разработчик в Базах не рубит, то лучше ему прямой SQL в руки не давать. это как гранатомет пятикантропу.... plain sql это конечно да, но это костыль - чтоб лазейка была когда по другому - ну ни как. кстати повышение произвотильности нельзя добиться по сравнению с качественных прямым кодом. а вот если код кривой - то как раз можно. всеж таки то что hibernate умеет он умеет хорошо и правильно. гораздо лучше и правельнее кривых рук. |
| Автор: jimur 16.5.2006, 17:37 |
| для меня основные недостатки: - непрозрачность - влияние на модель преимущества названы выше альтернатива для проектов, где одна база - Spring + чистый SQL |
| Автор: katala 16.5.2006, 17:49 |
| всем большое спасибо за помощь!!!! еще одна просьба: может кто подкинет ссылочки где материал можно взять про hibernate (одна уже есть www.hibernate.org) и про java где описывается именно работа с базами(как с использованием хибера так и обычный способ). а то мне курсовую надо писать разбирался то на английском но теперь красиво перевести не смогу.(знания английского не позволяют не тот уровень) может кто даст какой нибудь материал или ссылки по этим материалам. буду очень благодарен!!!! |
| Автор: jimur 16.5.2006, 18:00 |
| поищи тут: www.javable.com |
| Автор: ALKS 16.5.2006, 18:17 | ||
для меня приимущество Spring в данном случае не очень очевидны. стандартного класса-костыля для java.sql который содержит обертки для объектных типов и всякие мелочи типа универсального метода close()  размером в 200 строк и становиться самым самым предком вообщем-то хвататет... и никакой рефлексии |
| Автор: jimur 16.5.2006, 18:36 | ||
это вопрос личных предпочтений не люблю костылей в своем коде, люблю писать мало простого кода... рефлекшн кстати там тольно на стадии инициализации используется, что есть мизер |
| Автор: ALKS 16.5.2006, 19:48 |
| свой самодельный костыль или костыль фирмы Spring? разницы по сути - никакой. |
| Автор: jimur 16.5.2006, 20:39 | ||
почти... только чем больше используется код, тем меньше вероятность ошибки в нем |
| Автор: ALKS 16.5.2006, 20:49 | ||||
скажи это Microsoft на самом деле у меня консервативный взгляд, я предпочитаю избегать использование сторонних либ если без этого можно малой кровью обойтись. ну вот параноя у меня такая. |
| Автор: jimur 16.5.2006, 20:55 | ||
да, согласен, есть нюанс - прозрачность кода (открытость + !навороченность) IoC + удобные врапперы спринга _много_ крови экономят |
| Автор: Tony 17.5.2006, 09:30 | ||||||
Ты не одинок  .Часто бивает, что в исползуемом продукте bug.А новый релиз через 6 мес. |
| Автор: ALKS 17.5.2006, 11:50 |
| Угу... это если этот новый релиз будет вообще. Я попал однажды в ситуацию, когда нам предложили поцеловать фреймворк torque строго в то самое место... |
| Автор: pvo 18.5.2006, 00:00 | ||
А что с ним? Почах? |
| Автор: ALKS 18.5.2006, 10:11 |
| мы попали строго в момент между версией 3.1 и 3.1.1 проект был мёртв 100%. никаких изменений практически никакго комъюнити никакой возможности достучаться до разработчиков.(мы нашли баги и пытались достучаться) потом torque как-то реанимировали, незнаю как - к тому времени я уже покинул тот проект... ощущение было очень мало приятное, признаться. народ уже поговаривал, тоскливо, о необходимости перехода на то самое что мы тут изначально обсуждаем. |
