ArticlesTutorialsInterview Questions & AnswersCertificationsFree Books & Sample ChaptersTechnical Discussions  Your Account | Advertise with us | Feedback |
Few pages of this site are under construction and we are constantly trying to improve it. If you have any suggestions or ideas about how to improve the site, please Let us know.
Hibernate Vs iBatis

Hibernate Vs iBatis

                     developersBOOK.COM , 11/28/2007

Hibernate Vs. iBatis?
Hibernate or iBatis or both ? Which is better?
Which one to use and when?


These are the few questions that continuously get asked in most of forums.
Whatís really difference between two and really more importantly when should I use one over the other. Its pretty interesting question because there are major differences between iBatis and Hibernate.


Within in the java persistence there is no one size, fits all solution. So, in this case Hibernate which is a de facto standard is used in lot of places.


Let us consider a scenario where Hibernate work great for initial model. Now Suddenly if you are using stored procedures, well we can do it in Hibernate but its little difficult; ok we map those, all of sudden we got some reporting type of queries, those donít have keys have group bys; with some difficulty here we can use name queries and stuff like that, but now starts getting more complicated, we have complex joins, yes you can do in hibernate, but we canít do with average developer. We have sql that just doesnít work.


So these are some of the complexities. One of the other things I find is, if am looking at an application that doesnít work very well with an ORM, aside from these considerations of using stored procedures, already using SQL, complex joins. In other words, Hibernate works very well if your data model is well in sync with object model, because ORM solutions like Hibernate map object to tables. However, letís suppose data model is not in sync with object model, in this case you have do lot of additional coding and complexities are entering into your application, start coming the beyond the benefits of ORM. So, again all of sudden you are noticing that the flow is gone; our application is becoming very very complex and developers canít maintain the code.


This is where the model starts breaking down. One size does not fit all. So this is where I like to use iBatis; as the alternative solution for these type of situations, iBatis maps results sets to objects, so no need to care about table structures. This works very well for stored procedures, works very well for reporting applications, etc,.


Now the question is , does it work well for simple CRUD applications? Well, it works because what we have to write is sql. Then why not use Hibernate for that?


You can start see Some of the decision criteria that comes into play. So one of the other follow on questions that typically get is , can I use both? Thatís really interesting question! because the answer is sure.


But,such a thing will never ever exists is java persistence world. However we can kind of use both to create this little hybrid. So think of this kind scenario, we have very large application where Hibernate is working very well for it, but we have a reporting piece that just is a real nag , its query only , so we can do is, we can use iBatis to pull up the queries for reporting piece and still use Hibernate for all the operational stuff and updates. This model actually works well, it doesnít break the transactional model, and it doesnít affect any of the primary & secondary caches with a Hibernate. Itís a good solution.


  • Use iBatis if
    • You want to create your own SQL's and are willing to maintain them
    • your environment is driven by relational data model
    • you have to work existing and complex schema's
  • Use Hibernate if
    • your environment is driven by object model and wants generates SQL automatically

The message is,

  • One size does not fit all the java persistence and the important to know there are other solutions besides the traditional ORMs, and that would be iBatis.
  • Both the solutions work well, given their specific domain.
  • Look for the opportunity where you can use both.


Back to top


    Add this Article to :
Del.icio.us
Digg
Google
Spurl Slashdot
Y! MyWeb
Blink
Furl
 

  ALSO SEE :

About Us | Our Mission | Terms of use | Author Terms |    Search        | Contact Us | Advertise With Us | Link to Us | Sitemap
Copyright © 2008 developersBOOK.COM. All rights reserved.