Freezer Persistence Generator versus ORM tools

July 24, 2017 in Articles

Note: This article was published by The Server Side on the 3rd July 2014.

Author: Victor Manuel Cerdeira Lopez

Freezer is a code generator which constructs the persistence layer of a Java application: DAOs, DTOs, JUnit tests, database tables and database documentation. This article compares the use of the DAOs generated by Freezer, with the use of an ORM tool, like for example Hibernate.

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 to a particular table: insert, select, delete, update; and when it returns or receives a DTO as a parameter, having an attribute for each column of that table.

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 those DAOs using descriptors of the entities involved in an application data model. Freezer is one of those code generators: it allows you to specify your entities using annotated Java classes.

In the last years, I have observed the tendency of using ORM tools in order to manage the persistence layer of a Java application. I suppose the main reason to choose an ORM tool is to avoid writing the persistence code, but you can also achieve the same objective using a code generator.

In my opinion the use of the traditional DAOs and, in particular the use of Freezer, has the following advantages over an ORM tool:

  • Traditional DAOs and Freezer involve simpler concepts, so it is easy to learn how to manage them than learning an ORM tool. In this way, I consider it is easier to implement operations such as: Recover the strictly required set of tuples, the utilization of Joins and aggregated functions, the use otimization HINTS, etc.
  • Performance: Code generation takes place before compile time, therefore the generated DAOs do not require of any interpreter at runtime, like an ORM tool does.
  • Adaptability: It is possible to adapt the generated code to some user’s specific requirements, or it is even possible to adapt to code generator in order to obtain automatically code adapted to their needs. All the source code is available at any moment, so the user might change it whenever they want, for instance, in order to optimize a particular generated query.
  • Finally, in my opinion, the great advantage of an ORM tool is that it hides the details of the database and it allows the user to design an application only using object orientation concepts, but I think this is a double edged sword, because it implies some loose of control with the database. As Martin Fowler says in his 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”.