I recently posted a link about building a CRUD application using Hibernate. (It also mentions using RESTFul web service using Jersey. We will ignore that for this post).
Persistence refers to storing data in storage. To a business applications, this is typically a Database. A database can be built using any technology (even Excel file could be construed as a database), they tend to be built on Relational technology.
CRUD refers to Create, Read, Update and Delete – typical operations performed on a database. This terminology goes way back to the early 80s. This is applicable to anywhere you read or write to a persistence storage. Any library or API developed to do persistence, will have to support these 4 operations.
With Java, we have an object oriented language writing to Relational database table(s). Think about it: A Java object typically has attributes and method and the table has columns and they may not be one-to-one. So, to copy what’s in an object to a table, you will have to methods to extract data, build and execute SQLs, so the data will be saved in the database table. To retrieve, you have to do the opposite. This is how most of the Persistence programs were written.
To simplify the interface to the database, then you had JDBC drivers and libraries to provide uniform methods. Even so, you had to write a lot of JDBC calls to make the persistence happen in Java code. As always, people thought, what if that can be automated?
This is the concept behind Java EJB entity beans (part of Java J2EE specifications). You create entities (objects) and map to database tables or setup methods, so what is in the Entity bean is copied to the database. The main program itself only knows about the entity bean while the entity bean knew about database table, it corresponded to. Up until EJB 2.x specification, this is what we had.
During the days of EJB Entity beans (Ejb 1.x, 2.x), the object to relational database table got so tedious. Technically, your entity bean mapped to a table took care of it, but the design got quickly complex and even affected performance. You have to go through Object-relational impedance mismatch, because objects and database tables are designed differently. This meant, often times, you entity bean had to do bean managed persistence – means a lot of coding.
In came Hibernate, circa 2001, an Object to Relational Mapping (ORM) tool. What if the mapping can be extracted outside of the EJB container and made simpler? Hibernate provided exactly that. You could define an XML file for such an object to Relational table mapping, thus simplifying the program itself.
One downside to this design is that the SQLs generated out of this may be too convoluted. Also, it abstracts underlying data at the object level, we may forget the true nature of relational design (normalization etc).
Almost all framework support some type of ORM implementation. Active Record pattern implemented in Ruby on Rails is essentially an ORM implementation in Ruby. And for Java, there are lot more options available now.
- Spring DAO
Even Java library has one now. EJB 3.x specification rewrote the entity bean to be independent, that it became a library called Java Persistence API or JPA.
And there are also persistence API like iBatis (since renamed as myBatis) that is more SQL centric, but the SQLs themselves were moved to XML, instead of code. JOOQ built similarly. SQL based ORM tools may be faster for query (because you can include a tuned query here), but may do not so good with updates to the database.
What to use for Java Persistence?
If you have an existing database that is heavily normalized, you may be better off using JDBC. On the other hand, if you are designing a brand new application, you may be able to design your objects and the relational tables properly, so an ORM tool can get the job done nicely.