1) Introduction
Persistent data can be seen anywhere in an application. Managing persistent data is one of the
few challenges that modern technologies/products are facing. A solution called Object-Relational
Mapping (ORM) has gained major popularity over the past few years. ORM is a piece of
software/product for the representation and conversion of data between the database and the
object-oriented programming language. Hibernate is one such ORM solution and it is an open-source
project.
Hibernate Framework Articles & Books
Though Hibernate is not the only persistence solution, it has become very famous over the recent
past because of its huge variety of features when compared with its competitors. It takes much of
the database related boiler-plate code from the developers, thereby asking the developers to
concentrate on the core business logic of the application and not with the error-prone SQL syntax.
2) Persistence
The definition of persistence can be given like this, "Data that can be stored to some permanent
medium and can be seen at any point of time even after the application that created the data has
ended". Persisting (or preserving) data is not an easy task and it is one of the basic necessities
for almost any application. The common storage mediums that we see in our day-to-day life are
hard-disk and a database.
Databases are the most preferred storage medium for persisting data because of the relatively simple
way for data-access using the Structured Query Language (SQL). Data within a database can be viewed
in a table format, where each row in the table represents a single record of data.
3) Object-Relational Mapping
As mentioned in the introductory part, ORM software greatly simplifies the transformation of
business data between an application and a relational-database. ORM can be viewed as a bridge
between an application and the relational-database that it is depending on.
The following picture clearly depicts that:
ORM acting as a bridge between the application and the database
As one infer from the above picture, application depends on the ORM for all the
database-related services like persisting service (for saving the data), query service
(for retrieving existing data from the database) and the ORM takes care of communicating with
the appropriate database.
Some of the most popular ORM project/products are iBatis Data Access Objects from Apache,
NDO (.NET Data Objects) for .NET languages, TopLink from Oracle and
PowerDesigner.
4) Comparison with other Technologies
Before the advent of Hibernate, there were so many other technologies and specifications
from Sun, for persistence. Few are them are explained in detail in the following sections
along with their drawbacks which led them not being able to become a successful one.
4.1) Problems with JDBC
Java provided an initial solution for persistence in the form of JDBC and developers are
depending on JDBC API's to connect to the database. One of the major drawbacks of JDBC is
that, one has to embed the application's data into the SQL syntax, i.e., for saving the data
in an application, the business object has to be converted to relational-object model by embedding
the various pieces of data within the SQL language syntax.
Consider the following situation, there is a business object called Employee with properties name
and age and this has to be persisted to a database.
The following is the class representation of the Employee class,
class Employee
{
private String name;
private int age;
//Other Methods go here.
}
Employee employee = getEmployeeObject();
String sqlInsertStmt = "INSERT INTO EMPLOYEE VALUES ('" + employee.getName() + "', '" +
employee.getAge() + "')");
statement.executeQuery(sqlInsertStmt);
The above is generally a poorer code, and also the business object (Employee object, in our case)
is tightly integrated with the SQL syntax.
During data retrieval, the reverse of the above process will happen. The information that is
fetched from the database has to be mapped to the business object. Consider the following piece
of code which has the conversion process of representing the business object from the relational
data model.
String sqlQueryStmt = "SELECT * FROM EMPLOYEE WHERE EMP_ID = '100'");
ResultSet employees = statement.executeQuery(sqlInsertStmt);
if (employees.next())
{
Employee fetchedEmployee = new Employee();
fetchedEmployee.setName(employees.getString("name"));
fetchedEmployee.setAge(employees.getInt("age"));
}
4.2) Entity Beans
Entity beans, which were one of the major components in the EJB Specification failed drastically
to provide a persistent layer in the applications.
The initial version of the EJB specification has little support for the Entity beans.
The first disadvantage is, an Entity Bean is not a local object, but a remote object, so,
there are overheads related to network performance issues. And the worst thing is that the
relationships between entity beans have to be manually managed in the application code and the actual
mappings were done in vendor-specific configuration files which invented lots of changes in the
configuration files when the application is made to point out to a different database server.
Though, the later version of the specification overcome many of the drawbacks that were found
in the initial versions by introducing the notion of local interfaces for representing an
enterprise bean and EJB Query Language (EJB-QL), etc., the art of designing and managing an
entity bean still yielded much complexity in the hands of the developers.
|
