iBATIS, Hibernate, and JPA: Which is right for you?

Object-relational mapping solutions compared

By K. L. Nitin, Ananya S., Mahalakshmi K., and S. Sangeetha, JavaWorld.com, 07/15/08

Object-relational mapping in Java is a tricky business, and solutions like JDBC and entity beans have met with less than overwhelming enthusiasm. But a new generation of ORM solutions has since emerged. These tools allow for easier programming and a closer adherence to the ideals of object-oriented programming and multi-tiered architectural development. Learn how Hibernate, iBATIS, and the Java Persistence API compare based on factors such as query-language support, performance, and portability across different relational databases.

In this article we introduce and compare two of the most popular open source persistence frameworks, iBATIS and Hibernate. We also discuss the Java Persistence API (JPA). We introduce each solution and discuss its defining qualities, as well as its individual strengths and weaknesses in broad application scenarios. We then compare iBATIS, Hibernate, and JPA based on factors such as performance, portability, complexity, and adaptability to data model changes.

If you are a beginning Java programmer new to persistence concepts, reading this article will serve as a primer to the topic and to the most popular open source persistence solutions. If you are familiar with all three solutions and simply want a straightforward comparison, you will find it in the section "Comparing persistence technologies."

Understanding persistence

Persistence is an attribute of data that ensures that it is available even beyond the lifetime of an application. For an object-oriented language like Java, persistence ensures that the state of an object is accessible even after the application that created it has stopped executing.

There are different ways to achieve persistence. The traditional approach to the problem is to use file systems that store the necessary information in flat files. It is difficult to manage large amounts of data in this way because the data is spread across different files. Maintaining data consistency is also an issue with flat-file systems, because the same information may be replicated in various files. Searching for data in flat files is time-consuming, especially if those files are unsorted. Also, file systems provide limited support for concurrent access, as they do not ensure data integrity. For all these reasons, file systems are not considered a good data-storage solution when persistence is desired.

The most common approach today is to use databases that serve as repositories for large amounts of data. There are many types of databases: relational, hierarchical, network, object-oriented, and so on. These databases, along with their database management systems (DBMSs), not only provide a persistence facility, but also manage the information that is persisted. Relational databases are the mostly widely used type. Data in a relational database is modeled as a set of interrelated tables.

The advent of enterprise applications popularized the n-tier architecture, which aims to improve maintainability by separating presentation, business, and database-related code into different tiers (or layers) of the application. The layer that separates the business logic and the database code is the persistence layer, which keeps the application independent of the underlying database technology. With this robust layer in place, the developer no longer needs to take care of data persistence. The persistence layer encapsulates the way in which the data is stored and retrieved from a relational database.

Java applications traditionally used the JDBC (Java Database Connectivity) API to persist data into relational databases. The JDBC API uses SQL statements to perform create, read, update, and delete (CRUD) operations. JDBC code is embedded in Java classes -- in other words, it's tightly coupled to the business logic. This code also relies heavily on SQL, which is not standardized across databases; that makes migrating from one database to another difficult.

Relational database technology emphasizes data and its relationships, whereas the object-oriented paradigm used in Java concentrates not on the data itself, but on the operations performed on that data. Hence, when these two technologies are required to work together, there is a conflict of interests. Also, the object-oriented programming concepts of inheritance, polymorphism, and association are not addressed by relational databases. Another problem resulting from this mismatch arises when user-defined data types defined in a Java application are mapped to relational databases, as the latter do not provide the required type support.

Archived Discussions (Read only)

Subject

If you got unexpected e-mail from Network World By agaffin

Forum migration update By Athen

Building a better forum - beta testers needed! By Athen

Hibernate allows complete control over mapping SQL By DavidKarr