An Introduction to iBatis (MyBatis), An alternative to Hibernate and JDBC

Hello Friends,

In recent interview, Interviewer asked me “Have you hands on iBatis?”  I simply said “NO“;  now she asked me “Give me some brief of it”. Again i am speechless. and then i am researching on it and share with you.

For those who does not know iBatis/MyBatisyet, it is a persistence framework – an alternative to JDBC and Hibernate, available for Java and .NET platforms. I’ve been working with it for almost two years, and I am enjoying it!

The first thing you may notice in this and following articles about iBatis/MyBatis is that I am using both iBatis and Mybatis terms. Why? Until June 2010, iBatis was under Apache license and since then, the framework founders decided to move it to Google Code and they renamed it to MyBatis. The framework is still the same though,  it just has a different name now.

I gathered some resources, so I am just going to quote them:

What is MyBatis/iBatis?

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the MyBatis data mapper over object relational mapping tools.To use the MyBatis data mapper, you rely on your own objects, XML, and SQL. There is little to learn that you don’t already know. With the MyBatis Data Mapper, you have the full power of both SQL and stored procedures at your fingertips.

iBATIS is based on the idea that there is value in relational databases and SQL, and that it is a good idea to embrace the industrywide investment in SQL. We have experiences whereby the database and even the SQL itself have outlived the application source code, and even multiple versions of the source code. In some cases we have seen that an application was rewritten in a different language, but the SQL and database remained largely unchanged.

It is for such reasons that iBATIS does not attempt to hide SQL or avoid SQL. It is a persistence layer framework that instead embraces SQL by making it easier to work with and easier to integrate into modern object-oriented software. These days, there are rumors that databases and SQL threaten our object models, but that does not have to be the case. iBATIS can help to ensure that it is not.

What is iBatis ?

  • A JDBC Framework
  • Developers write SQL, iBATIS executes it using JDBC.
  • No more try/catch/finally/try/catch.
  • An SQL Mapper
  • Automatically maps object properties to prepared statement parameters.
  • Automatically maps result sets to objects.
  • Support for getting rid of N+1 queries.
  • A Transaction Manager
  • iBATIS will provide transaction management for database operations if no other transaction manager is available.
  • iBATIS will use external transaction management (Spring, EJB CMT, etc.) if available.
  • Great integration with Spring, but can also be used without Spring (the Spring folks were early supporters of iBATIS).

What isn’t iBATIS ?

  • An ORM
  • Does not generate SQL
  • Does not have a proprietary query language
  • Does not know about object identity
  • Does not transparently persist objects
  • Does not build an object cache

Essentially, iBatis is a very lightweight persistence solution that gives you most of the semantics of an O/R Mapping toolkit, without all the drama. In other words ,iBATIS strives to ease the development of data-driven applications by abstracting the low-level details involved in database communication (loading a database driver, obtaining and managing connections, managing transaction semantics, etc.), as well as providing higher-level ORM capabilities (automated and configurable mapping of objects to SQL calls, data type conversion management, support for static queries as well as dynamic queries based upon an object’s state, mapping of complex joins to complex object graphs, etc.). iBATIS simply maps JavaBeans to SQL statements using a very simple XML descriptor. Simplicity is the key advantage of iBATIS over other frameworks and object relational mapping tools.

Who is using iBatis/MyBatis?

I think the biggest case is MySpace, with millions of users. Very nice!

Some more users here.

Hope you will like this. Cheers… 🙂

Advertisements

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.