• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Compare Ibatis to Hibernate?

 
Tom Fulton
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could the authors of the "Ibatis in Action" book describe the differences (advantages/disadvantages/features) between Ibatis and Hibernate?

Also, I noticed that Java DAO framework was deprecated in the new version of Ibatis, and I was wondering if the reasons for that could be explained.

Thanks!
 
Clinton Begin
author
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>> (advantages/disadvantages/features) between Ibatis and Hibernate?

Hibernate and iBATIS very different frameworks and are therefore difficult to compare. iBATIS was released the same week that Hibernate was, and the projects were largely unaware of each other. Given that there were 30 some-odd ORM frameworks before Hibernate, I think iBATIS survived because it is so different. So how is it different?

First, iBATIS isn't an ORM at all by strict definition. It doesn't support OID or object identity, and it doesn't map classes to tables. Instead iBATIS maps objects to SQL statements. By objects I mean literally they are mapped at an instance level to the SQL statement. The advantage here is that you can very easily map to JavaBeans like Hibernate, but also to primitives, collections like Maps, and even XML. iBATIS is also almost limitless in its flexibility to map any object model to any data model. It makes no assumptions about now normal the database is, or whether the table has a primary key or if the bridge table has actual data in it or not.

Of course, it's a little more work than Hibernate, because you have to write SQL. However, there are tools that you can use to seed your SQL maps with initial CRUD type functionality (see Abator) and in the .NET version they even support generation tags for generating boilerplate CRUD statements.

There are some other minor differences. The most notable is that because iBATIS doesn't support OID, caching is significantly "dumber" than an ORM can be. However, modern best practice suggests that we should be caching as high up in our application layers as possible anyway. In other words, performance benefits gained by caching are greater at the presentation tier than they are at the persistence tier, and we probably shouldn't cache things twice. Therefore, I'd suggest caching at the web tier almost exclusively, and writing business specific caches at your logic/service layer on a case-by-case basis. This allows the database to do its job without introducing the complexities of a clustered caching solution.

Sorry....long answer, but as I said in the beginning. There's really no way to compare Hibernate and iBATIS on a point by point basis.

>> Also, I noticed that Java DAO framework was deprecated

So, as I described above, Hibernate and iBATIS are very different, which is why both have survived the last 4 years.

On the other hand, iBATIS DAO and Spring DAO were very similar. As it turns out Spring is not only more popular than iBATIS DAO, but it's also simply better. We're not here to reinvent the wheel, so we're now officially suggesting people use Spring for DAO.

Deprecation doesn't mean you can't use it...you're still perfectly welcome to download iBATIS DAO and use it, or take the code and make it your own.

We left the chapters on DAO in the book because DAO has been there for 4 years, and also I think there's a lot to be learned from the DAO chapters anyway.

Cheers,
Clinton
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65335
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As it turns out Spring is not only more popular than iBATIS DAO, but it's also simply better. We're not here to reinvent the wheel, so we're now officially suggesting people use Spring for DAO.


As I mentioned in another topic, the iBATIS team seems to have its head in a good and practical place. This is another example.

Respect +1
 
Timothy Toe
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
However, modern best practice suggests that we should be caching as high up in our application layers as possible anyway. In other words, performance benefits gained by caching are greater at the presentation tier than they are at the persistence tier, and we probably shouldn't cache things twice. Therefore, I'd suggest caching at the web tier almost exclusively, and writing business specific caches at your logic/service layer on a case-by-case basis. This allows the database to do its job without introducing the complexities of a clustered caching solution.


AFAIK, this best practise is not discussed/mentioned very often. Thanks for pointing that out.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic