А всё-таки, в случае сферического коня в вакууме, какой persistence solution лично Вы предпочли, iBatis, или же Hibernate? Хотелось бы услышать хоть какую-то аргументацию тоже...
P.S. Гуглил, разумеется, читал это, это и это. Но почему-то окончательно чёткого понимания что же лучше не возникло.
Всем зараннее спасибо за высказанные мнения, особенно если высказывающий успел поработать с обеими технологиями
Здравствуйте, slskor, Вы писали:
S>Вас реально интересует сферический конь?
Ага.
S>PS: Вообще-то у Hibernate есть FAQ, в котором написано, в каких случаях Hibernate лучше не использовать
Читал, но это не совсем то, что меня интересует... Хотелось бы услышать реальный отзывы людей, которые работали с обеими технологиями и прочувствовали разницу...
С hibernate'ом практически не работал но изучал, по крайней мере неплохо знаю его фичи.
С iBatis'ом работаю последнюю неделю
Как их можно сравнивать мне не очень понятно. Судя по всему вы имеете ввиду сравнение SqlMaps (компонент iBatis) и hibernate.
Так вот, SqlMaps это просто меппер SQL в ява бины, точка. Грубо говоря делает два действия:
1. Дали select SQL (пишется ручками в xml файле), выполнил его, -> заполнил данными java bean.
2. Дали java bean, сказали выполни вот тот insert/update/delete SQL (по id из xml файла) -> подставил значения из бина в запрос и выполнил его.
Из дополнительных фич там есть поодержка lazy loading. Т.е. при заполении бина библиотека может засеттить прокси data объекта, как только метод это объекта вызовется выполнится определенный select (опять же написанный руками в xml файле) который реально заполняет данный объект.
sqlmaps НЕ трекает изменения. Т.е. например есть data объект Page, у него есть свойство permissions которое является коллекцией объектов PagePermission. C помощью sqlmaps можно выбрать этот объект из базы. Можно даже используя прозрачный lazy loading получить коллекцию permissions. Но вот если теперь изменить эту коллекцию permissions то понадобиться ВРУЧНУЮ запоминать все добавленные/удаленные/измененные PagePermission'ы и для каждого из них вызывать соответствующий метод DAO. В случае же hibernate все изменения трекаются самой библиотекой и надо только вызвать save() на родительском объекте Page для сохранения графа всех измененных объектов.
з.ы. А еще sqlmaps не умеет сеттить свойства черех конструктор, т.е. для каждого свойства нужен setter (что часто не есть хорошо).
Hallo korostoff!
> з.ы. А еще sqlmaps не умеет сеттить свойства черех конструктор, т.е. для каждого свойства нужен setter (что часто не есть хорошо).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A Hibernate eto umeet? Ja kogda to zdorowo ogor4ilsja, 4to etogo ne na6el. Tknite pls..
Здравствуйте, Firstborn, Вы писали:
F>Здравствуйте, slskor, Вы писали:
S>>Вас реально интересует сферический конь? F>Ага.
S>>PS: Вообще-то у Hibernate есть FAQ, в котором написано, в каких случаях Hibernate лучше не использовать F>Читал, но это не совсем то, что меня интересует... Хотелось бы услышать реальный отзывы людей, которые работали с обеими технологиями и прочувствовали разницу...
Ну я работал. Разницу почувствовал. Что касается моих личных предпочтений, то они сильно зависят от предметной области. Трудоемкость разработки на iBatis выше. В изучении iBatis намного проще. Несколько раз сталкивался с задачами, которые решаются на iBatis без проблем, но, пожалуй, поставили бы меня в тупик при работе с Hibernate. Касаются они, в основном, оптимизации запросов хинтами, составления очень сложных запросов, составления динамических запросов. Несложные же приложения разрабатываются с помошью Hibernate на ура.
Понимаю что вам непременно сферический конь нужен, но я бы выбирал между iBatis и Hibernate в зависимости от задачи.
Re[4]: iBatis vs. Hibernate?
От:
Аноним
Дата:
11.09.06 03:32
Оценка:
Здравствуйте, slskor, Вы писали:
S>Ну я работал. Разницу почувствовал. Что касается моих личных предпочтений, то они сильно зависят от предметной области. Трудоемкость разработки на iBatis выше. В изучении iBatis намного проще. Несколько раз сталкивался с задачами, которые решаются на iBatis без проблем, но, пожалуй, поставили бы меня в тупик при работе с Hibernate. Касаются они, в основном, оптимизации запросов хинтами, составления очень сложных запросов, составления динамических запросов. Несложные же приложения разрабатываются с помошью Hibernate на ура.
+1
При использовании Hibernate, простите, затрахался писать большие и сложные запросы. С iBatis не работал, но уже возникло такое желание.
Здравствуйте, Аноним, Вы писали:
А>При использовании Hibernate, простите, затрахался писать большие и сложные запросы. С iBatis не работал, но уже возникло такое желание.
А что в iBatis с динамическим формированием запроса?
А>>При использовании Hibernate, простите, затрахался писать большие и сложные запросы. С iBatis не работал, но уже возникло такое желание.
AE>А что в iBatis с динамическим формированием запроса?
Это, конечно, крайний случай. Обычно динамика касается только WHERE-части SQL-запроса. Примерно так:
<statement id="dynamicGetAccountList" ... >
select * from ACCOUNT
<dynamic prepend="WHERE">
<isNotNull prepend="AND" property="firstName">
FIRST_NAME = #firstName#
</isNotNull>
<isNotNull prepend="AND" property="emailAddress">
EMAIL like #emailAddress#
</isNotNull>
<isGreaterThan prepend="AND" property="id" compareValue="0">
ID = #id#
</isGreaterThan>
</dynamic>
order by LAST_NAME
</statement>
Не все мне в iBatis нравится, некоторые вещи, имхо, можно было бы и поудобнее сделать, но не было еще задачи, которую я бы не смог решить средствами iBatis. Откровенно говоря, с Hibernate я себя менее уверенно чувствую.
Здравствуйте, slskor, Вы писали: S>Откровенно говоря, с Hibernate я себя менее уверенно чувствую.
Hibernate меня убивает своей неэкономностью...
Вот недавно инстанцировал один достаточно сложный объект (навернутый документ).
И включил лог запросов от hibernate... офигел, увидев что при инстанцированиий он выдал 87 запросов.
Ради прикола чуть подумал и выбрал то же ручками, получилось, что можно уложиться в 3...
Понятно, что его можно "дозатачивать напилником" и настраивать и еще раз настраивать... но не проще ли окажется просто запросы ручками написать?
Здравствуйте, Alex EXO, Вы писали:
AE>Hibernate меня убивает своей неэкономностью... AE>Вот недавно инстанцировал один достаточно сложный объект (навернутый документ). AE>И включил лог запросов от hibernate... офигел, увидев что при инстанцированиий он выдал 87 запросов. AE>Ради прикола чуть подумал и выбрал то же ручками, получилось, что можно уложиться в 3... AE>Понятно, что его можно "дозатачивать напилником" и настраивать и еще раз настраивать... но не проще ли окажется просто запросы ручками написать?
Странно у вас написан объект. Скорее всего, вы его вообще не настраивали. У меня вытягивает только то, что нужно. Но для этого я во время разработки лог запросов не выключаю, для контроля. С первого раза маппинги не напишешь идеально, поэтому в процессе они постоянно правятся.
Вообще, насколько я понял, одной из главных фичей Hibernate является минимизация количества запросов к базе.
Re[8]: iBatis vs. Hibernate?
От:
Аноним
Дата:
11.09.06 10:31
Оценка:
Здравствуйте, Alex EXO, Вы писали:
AE>Hibernate меня убивает своей неэкономностью... AE>Вот недавно инстанцировал один достаточно сложный объект (навернутый документ). AE>И включил лог запросов от hibernate... офигел, увидев что при инстанцированиий он выдал 87 запросов. AE>Ради прикола чуть подумал и выбрал то же ручками, получилось, что можно уложиться в 3...
Оптимизировать можно и пользуясь возможностями Hibrnate, ..для начала мапинг (..негоже поднимать с одним объектом зараз пол базы, ..наверное), ..кроме того Hibrnate гибок и все можно переопределиить.
AE>Понятно, что его можно "дозатачивать напилником" и настраивать и еще раз настраивать... но не проще ли окажется просто запросы ручками написать?
..ну с таким подходом, зачем вообще пользоваться ОРМ?)
Здравствуйте, Michael_Y, Вы писали:
M_Y> Странно у вас написан объект. Скорее всего, вы его вообще не настраивали. У меня вытягивает только то, что нужно. Но для этого я во время разработки лог запросов не выключаю, для контроля. С первого раза маппинги не напишешь идеально, поэтому в процессе они постоянно правятся.
О тож! Согласен...
Просто наши решили, что наличие hibernate это повод вообще не проектировать базу, а думать только на уровне объектов... ну и не учить sql, заодно.
Так что я не против hibernate, но против некоторых иллюзий на его счет.
Здравствуйте, Michael_Y, Вы писали:
M_Y> Вообще, насколько я понял, одной из главных фичей Hibernate является минимизация количества запросов к базе.
На мой взгляд, главное достоинство Hibernate в том, что он позволяет увеличить скорость разработки Database Access Layer. Практически, же скорость разработки ну очень сильно зависит от знаний и опыта разработчика, умения обращаться с hbm-ками или аннотациями. Вот и приходится постоянно гонять приложение с show_sql=true, дабы вовремя вправить системе мозги.
Но если говорить о минимизации запросов к БД, то iBatis наверняка впереди будет, просто потому, что там контроль за запросами абсолютный и полный. И это очень даже хорошо, если вы работаете с миллионами записей, потому что для ключевых запросов план в профайлере вылизывать надо, однозначно!
Кстати, в iBatis кэширование очень хорошо оттюнить можно.
Иметь flushInterval иногда очень даже полезно. А то, понимаешь, запускают приложение в 24x7, а потом его перенастроить не могут, потому что оно изменения в БД в упор не видит