iBatis, Hibernate, and JPA
Excellent JavaWorld article from Infosys architects(Nitin, Ananya, Mahalakshmi and Sangeetha). I have not come across, this much detailed comparison of object-relational mapping (ORM) technologies, in my recent memory.
But my take on this topic is we can use standard java database connectivity (JDBC) to create, update, read, delete (CURD) operation. The idea of using ORM is to decouple database layer from business logic, so that we can easily migrate to new database. I don’t think most companies are often changing database, other than start-ups, all companies are using standard one-time buy database software such as Oracle, DB2. This article really helps to sharpen ORM knowledge.
I compared software database role with football kicker role, yes, if we see kicker’s game time is very less like less than 5 mins but every 4th play depends on kickers, which means, 25% of play was executed by kickers. Kicker is the one setting next play position by punt and helping teams to win with last minute field goal. Kicker’s role may be limited but value is huge.
Based on my kicker analogy, my opinion is, we need a dedicated team for PL/SQL programming and write as much as store procedures and call those from standard JDBC for any external facing /enterprise applications, of course this approach also has some drawback, but better than all others, and internal applications can use ORM tools.
iBatis is great and more control over SQL than Hibernate. I think iBatis is providing a balanced approach of standard JDBC and ORM. We can directly plug-in SQL into XML file from PL/SQL developers or PL/SQL developer can work with XML files directly. This is definitely an added advantage over other ORM technologies. It provides good support for both iterative database changes as well as separating SQLs from Java code.
Hibernate very effective when we design Java object model first and based on that relational database model. Java object model drives database design is something new thought process and we are not there yet. Hibernate can’t handle a small mismatch between relational and object design. But it provides all robust supports for database layer such as auto SQL, transaction, which are completely missed in iBatis.
But my take on this topic is we can use standard java database connectivity (JDBC) to create, update, read, delete (CURD) operation. The idea of using ORM is to decouple database layer from business logic, so that we can easily migrate to new database. I don’t think most companies are often changing database, other than start-ups, all companies are using standard one-time buy database software such as Oracle, DB2. This article really helps to sharpen ORM knowledge.
I compared software database role with football kicker role, yes, if we see kicker’s game time is very less like less than 5 mins but every 4th play depends on kickers, which means, 25% of play was executed by kickers. Kicker is the one setting next play position by punt and helping teams to win with last minute field goal. Kicker’s role may be limited but value is huge.
Based on my kicker analogy, my opinion is, we need a dedicated team for PL/SQL programming and write as much as store procedures and call those from standard JDBC for any external facing /enterprise applications, of course this approach also has some drawback, but better than all others, and internal applications can use ORM tools.
iBatis is great and more control over SQL than Hibernate. I think iBatis is providing a balanced approach of standard JDBC and ORM. We can directly plug-in SQL into XML file from PL/SQL developers or PL/SQL developer can work with XML files directly. This is definitely an added advantage over other ORM technologies. It provides good support for both iterative database changes as well as separating SQLs from Java code.
Hibernate very effective when we design Java object model first and based on that relational database model. Java object model drives database design is something new thought process and we are not there yet. Hibernate can’t handle a small mismatch between relational and object design. But it provides all robust supports for database layer such as auto SQL, transaction, which are completely missed in iBatis.
Comments