Hibernate and iBatis

[stateofmind]

Hi everyone, I've a newbie to Spring (2 weeks old) and have been converting some applications from work to use Spring and it's MVC. It's my goal to draw my company away from our homebrewed framework and use Spring instead.

I'm also somewhat new to Hibernate and iBatis. Can you explain the pros/cons of Hibernate and iBatis? I'm using iBatis currently, and love it. I love having all the SQL in assorted XML files. In Hibernate, I don't like the HQL being in the code itself. Of course I may be way off, as I've only worked with Hibernate in some small test applications.

Any help appreciated, thanks everyone. 8)

Josh

[Rod Johnson]

Hibernate and iBATIS are different animals.

Hibernate offers fairly transparent O/R mapping, similar in concept to products like TopLink and JDO implementations. It's based on the idea of mapping objects to the database.

iBATIS doesn't transparently persist, but maps statements to the database. So it's somewhat like a better JDBC.

They're both good products IMO. iBATIS is well suited to deal with really complex SQL and nasty legacy relational schemas. Hibernate is a good general O/R mapping solution.

Btw you can pull your Hibernate queries into your config XML files if you don't want them in Java code.

Of course Spring works beautifully with both, within our consistent data access strategy, so you can choose the better solution of the 2 on a case-by-case basis if you want.

There's a summary of the pros and cons of various data access approaches, including Hibernate and iBATIS, in the Persistence chapter of "J2EE without EJB".

Rgds
Rod

[ahmetaa]

i agree that Hibernate and IBtais are different. As we use, and to my understanding, Hibernate is a higher level system than IBatis. Such as, with hibernate you do not need to know any SQL or DB spesific thing.
if you want to mess with spesific jdbc operations, stored procedures etc, Ibatis might be way to go (or Spring jdbc maybe?). But Hibernate gives you more freedom and transparency over databases choices. We could switch between oracle, HSQLDB, MSSQL with literally no change (except three configuration lines)
Dont see HQL as a bad thing, i find it easy to understand and use over SQL. Spring's hibernate template is a nice time saver. with spring you dont need to give a lot of consideration to Hibernate transaction mechanism either. And documentation and community support for Hibernate is very good.
One thing i do not like about hibernate is the number of dependant libraries. For a full blown application you need to use at least 7-8 external libraries. But ibatis is a single jar file (or two). Also hibernate learning curve can be a little steep in some issues. Well, consider your projects situation make some tests and decide quickly i say.

[Martin Kersten]

with hibernate you do not need to know any SQL or DB spesific thing.

I don't think so. Also I guess the hibernate folks don't think so. You should understand, what you are about to do and what the effect will be. Hibernate offers a very high level of frustration. And if you couldn't even read the produced SQL statements, you may not know why your assoziation leads to a resave or why it refuses to deal with a certain table. So please, quickly remove the 'any' from the 'know any SQL or DB specific thing' statement.

It's the same like 'you shouldn't go swimming, if you can't dive', I guess - You need to get wet even using Hibernate.

Hibernate is an object<-->relational (O/R) mapping solution. Once you have checked it, it is easy to use and tests can be written easily.[/quote]

[ahmetaa]

Martin,
you are right, i shouldnt have said that "you dont have to know any..". but in our project, i did not writte one single line of SQL (i checked the produced SQL statements tough, they were well). So in theory statement is correct as long as things go as expected.
Granted, our application do not contain hundreds of tables, but hey, i said my experience.
Otherwise it is common sense that it wouldnt be wise to deal with relational DB's without knowing SQL or behavior of a particular DB.

[saden1]

Hibernate has two disadvantages IMO:
1. You can't map one class to multiple tables dynamically.
2. It can generate bloated and un-optimized SQL queries.

[reza]

Hallo Saden1,

Hibernate has two disadvantages IMO:
1. You can't map one class to multiple tables dynamically.

It's not correct at all. You can map one class dynamically on multiple tables depend on, say, the value of an attribute.

The only thing you need it to define more then one mapping file for that object an using of so called entity-name.

Hibernate 3.0 has a lot of problems by deleting objects using aliases (entity-name). We use hibernate 3.1 (BETA) und it works perfectly.

Regards
Reza[/code]