Are your DAOs making you feel DOA? Maybe Freezer is the answer?


News: Are your DAOs making you feel DOA? Maybe Freezer is the answer?

  1. I’ve got a background in Hibernate and ORM. A little book I penned, named Hiberante Made Easy, was surprisingly a best seller, and before I got knee deep into TheServerSide, I managed to squeak out a living doing the occasional consulting gig where I was put in charge of designing how the service tier communicated with the data tier. Sadly, more often than not, that meant managing and maintaining a system of so many DAOs that you felt like you were DOA as soon as you opened up the code.

    Java EE, JPA and the way the various entity managers work has reduced the need for many projects to go whole hog in terms of creating DAOs to service every table in their ERD, but like any technology, there is always a time and a place where its use just makes sense. But doing what makes sense doesn’t necessarily make doing it easy, especially when it comes to the Data Access Object pattern. That’s why Freezer got my attention when Victor Manuel Cerdeira Lopez pitched it to me. “Freezer is a code generator that constructs the persistence layer of a Java application, including DAOs, DTOs, database tables and database documentation,” according to the article Lopez wrote for TSS.

    I’d still like to see DAOs go the way of the dodo bird, but that’s not likely going to happen. And if that’s not happening for you, do yourself a favor and check out Freezer. It just might save you a great deal of time and frustration.

    Freezer: Putting ORM Tools to the Test

    Follow Cameron McKenzie on Twitter: @potemcam


    Threaded Messages (3)

  2. DTO not VO[ Go to top ]

    As of this writing the tutorial inappropriately refers to Data Transfer Objects (DTOs) as Value Objects (VOs). This is incorrect and spreads the misuse and furthered ambiguity of architecture terms that is already rampant in our industry.


    A Value Object follows Value Semantics not Reference Semantics. For instance, Money, Currency, DateRange - these would all be VOs.


    BankAccount or AppointmentSchedule might be objects which contain references to several different values and so follow Reference Semantics. As a result, BankAccount and AppointmentSchedule would not be VOs. If these two objects contain no logic then you might call them DTOs or Beans or possibly several other names depending on their use and purpose.


    The reason it is incorrect to use VO to describe a DTO is that you then either have no widely used term for what I described above as Currency, DateRange, etc.. Or if you use the VO term for both then there is ambiguity. The purpose of nomenclature is to reduce ambiguity and aid in communication. So if there are two different widely accepted paths for the nomenclature of a field to take, the one that reduces ambiguity and makes communication clearer is the winner.


    DTO != VO

  3. add to it[ Go to top ]

    Just because the objects have no business logic does not mean they are DTOs. DTO is merely is a pattern to extract all the properties from an object so it can be "transfered" over the network and then reconstituted into the object again on the other side. This is only needed when you have non-serilizable objects or each property call results in a network call. While there are other reasons to extract one or more values from an object or objects (such as to create an object that works like a database view), they are not DTOs. DTOs effectively died with EJB3. While i have many "view" objects, I've not had the need for DTOs since ... I started using an ORM.

    If you have objects that directly match your table structure, you dont have DTOs. You have "table" objects. DAO and DTO are not related. In fact, it pretty much means you dont need them. No need to name them "VO" either. Just use a  name that basically matches the table. Other developers will know they are not "entity domain objects" when they don't see any collections and just IDs to other tables.

  4. Model Driven Development tools like AndroMDA, Visual Paradigm, and Clear Toolkit have been around for a while.  Maybe Freezer is better than those products, more user friendly, or something like that, but when all is said and done, if you have to generate large amounts of Java code, you're probably doing it wrong.

    In my opinion, this is not Object Oriented programming.  You're probably using an OO language to write procedural code.  The more tables you have, the more code you need to write and maintain.  Learning and implementing polymorphism will keep you out of DAO hell.  Here is the approach I've successfully implemented after once mistakenly going down the road the article is trying to help you avoid:

    1) Use a UML tool to generate the DDL scripts and bring up the DB.

    2) Use JBoss Tools/Hibernate Tools to generate JPA annotated POJO's to represent the tables. (Or, you could generate the POJO's and Hibernate mapping documents if that's your preferred route)

    3) Make all of those JPA objects extend a base class, I.E.  AbstractPersistentObject

    4) ***HERE'S THE BIG ONE*** Write ONE (1) single DAO, in which the methods arguments and return types are all AbstractPersistentObject.

    5) In your Service layer or Controller classes, call the single DAO methods directly, and type cast the results.

    Maybe I should write up a guide or article on this, let me know folks.