Hibernate vs iBatis

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


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.

Jasper Report vs iBIRT Report

BIRT is the only reporting tool that is part of the Eclipse foundation. That alone is enough for me. The IDE is easy-to-use and you can design reports using a really intuative WYSIWYG designer. When things get more complex, you have the APIs and scripting hooks to handle it. After you design the report itself, you have a ton of deployment flexbility.

My short list of reasons I would go with BIRT:

  1. Data agnostic designer: JDBC, Native Drivers, Web Services, POJOs
  2. Eclipse-based: The community in and around BIRT & Eclipse is thriving.
  3. Drag-andDrop report creation: No programming is required to create content
  4. Versatility: You can create all kinds of content with BIRT, not just traditonal BI.
  5. Easy to deploy: Eihter embedded in an application or stand-alone
  6. Once executed and built, BIRT Report Documents are stand-alone entities. This really increases deployment options since you no longer need access to source data and resources for the users to view the report. Gets around firewall issues, security problems, etc… Really flexible execution.

Good luck no matter which way you go!

P.S. I did leave off one huge feature, and that is Page Level Security. If you want to develop one large report for a differentiated audience, you can do that in BIRT and rely on the tool to distribute the proper pages to the appropriate users. This can be a HUGE savings in resources (i.e. not generating 100 separate reports, but rather generating one report and slicing it up as many times as you need).

Jasper vs iBirt comparision matrix:

http://www.innoventsolutions.com/birt-jasper-pentaho-comparison-matrix.html

http://www.innoventsolutions.com/birt-vs-jasper.html