Feature:

Freezer: Putting object relational mapping (ORM) tools to the test

By Victor Manuel Cerdeira Lopez

TheServerSide.com

Freezer is a code generator that constructs the persistence layer of a Java application, including DAOs, DTOs, database tables and database documentation. This article compares the use of the DAOs generated by Freezer with the use of other common ORM tools such as Hibernate.

The data access object (DAO) dilemma

For years the traditional DAO pattern has proved its effectiveness managing the access to a relational database. In this article, we define a DAO as traditional when it implements, usually using JDBC, the operations to access a table, operations such as insert, select, delete, update. Furthermore, when a DAO returns or receives a DTO as a parameter, that DTO has an attribute for each column of the table managed by the DAO.

In the beginning, these kind of DAOs were handwritten, a tedious and error-prone task. As most of the code of a DAO is repetitive, code generators appeared in order to create the DAOs from descriptors of the entities involved in the data model of an application. Freezer is one of these code generators, allowing you to specify entities using a UML diagram or XML descriptors. These descriptors can even be automatically built from an existing database using the provided reverse engineering tool.

In the beginning, these kind of DAOs were handwritten, a tedious and error-prone task.

Freezer's value proposition

In the last years, I have observed the tendency to use an ORM tool to manage the persistence layer of a Java application. I suppose the main reason to choose an ORM tool is to avoid writing most of the code of the persistence layer, but you can also achieve this objective using a DAO generator.
In my opinion the use of the traditional DAOs and, in particular the use of the DAOs generated by Freezer, has the following advantages over the use of an ORM tool: 

  • Better performance: With a traditional DAO and with Freezer, it is easier to implement operations such as: Recover the amount of tuples strictly needed, the use of JOINs, the use of aggregated functions, the specification of HINTS to get an optimum access, etc.
  • Code generation takes place before compile time, therefore the generated DAOs do not require any interpreter at runtime, like an ORM tool does.
  • The use of traditional DAOs implies an easier learning curve. The following features make easy to learn Freezer: inclusion of graphical tools, simple configuration syntax and comprehensive documentation with tutorials and examples.
  • Adaptability: Changing the implementation of the Freezer generator module, it is possible to get code adapted to your project’s specific requirements, for example: code adapted to the logging system your project uses, code in another programming language (ex: C++), or code that access to another kind of database (ex: EMC Documentum). I think the use of an ORM tool is not so flexible.
  • In my opinion, the great advantage of an ORM tool is that it hides the details of the database schema and it allows you to design the application more in terms of object orientation, but I think this is a double edged sword, because of the loose of feeling with the database access that it implies. As Martin Fowler says in the article ORM Hate: “Many people treat the relational database like a crazy aunt who is shut up in an attic and whom nobody wants to talk about”.

Of course, seeing is believing, or at least, working with a given product is believing. If you want to challenge your beliefs when it comes to ORM based toolings, check out this introductory tutorial on using Freezer:

Tutorial of how to use Freezer Persistence Generator:

How are you creating your underlying DAO classes? Let us know.

 

03 Jul 2014

Related Content

Related Resources