Home/ Questions/Q 344235
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T10:58:18+00:00

Data Access Objects (DAOs) are a common design pattern, and recommended by Sun. But

  • 0

Data Access Objects (DAOs) are a common design pattern, and recommended by Sun. But the earliest examples of Java DAOs interacted directly with relational databases — they were, in essence, doing object-relational mapping (ORM). Nowadays, I see DAOs on top of mature ORM frameworks like JDO and Hibernate, and I wonder if that is really a good idea.

I am developing a web service using JDO as the persistence layer, and am considering whether or not to introduce DAOs. I foresee a problem when dealing with a particular class which contains a map of other objects:

public class Book {
    // Book description in various languages, indexed by ISO language codes
    private Map<String,BookDescription> descriptions;
}

JDO is clever enough to map this to a foreign key constraint between the “BOOKS” and “BOOKDESCRIPTIONS” tables. It transparently loads the BookDescription objects (using lazy loading, I believe), and persists them when the Book object is persisted.

If I was to introduce a “data access layer” and write a class like BookDao, and encapsulate all the JDO code within this, then wouldn’t this JDO’s transparent loading of the child objects be circumventing the data access layer? For consistency, shouldn’t all the BookDescription objects be loaded and persisted via some BookDescriptionDao object (or BookDao.loadDescription method)? Yet refactoring in that way would make manipulating the model needlessly complicated.

So my question is, what’s wrong with calling JDO (or Hibernate, or whatever ORM you fancy) directly in the business layer? Its syntax is already quite concise, and it is datastore-agnostic. What is the advantage, if any, of encapsulating it in Data Access Objects?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It depends what your layer’s goals are. You put an abstraction in to supply a different set of semantics over another set. Generally further layers are there to simplify somethings such as development of future maintennance. But they could have other uses.

    For example a DAO (or persistence handling) layer over an ORM code supply specialised recovery and error handling functionality that you didn’t want polluting the business logic.

    • 0