Hello!

I would like to abstract from the hibernate dependent code by using the DAO pattern. As I understand the pattern, there should be one DAO for each business object. This DAO implements CRUD operations which give access to the data of the business object.

By using this approach, however, a scalar query that returns properties from several classes cannot (efficiently) be implemented anymore. I would have to call one DAO method after another to gather the needed information. (Example: I would like to generate a summary table, that lists some properties of different classes).

If I were to implement a DAO which does not pertain to a particular business object and which implements special queries like these efficiently (using HQL) and gives me the result in a transfer object, would that be bad design?

Thanks a lot!
Jonas

There's two options I've seen used. The one you mention, and another where the DAO for the main entity involved in the report/summary contains a method to gather all the required data.

I think either is a valid approach.

And, I don't think its a bad design. There is always going to be one-off use-cases which to not fit nicely into the arch. of the rest of the system. Things like on-the-fly reports within a OLTP system (basically what you are trying) are a good example.

we are working with a "fine grained" DAO layer, it works fine, in your particular case... you'll have to write some "generic" or "exclusive" DAO.

What you can think about is "cutting" your domain model in 10 business zones (10 is an example ;) ), and have one DAO per zone.

Thank you very much for your input! Good to know I'm not off track.

Jonas