About Data Objects and DAO Design when using Hibernate

Posted by X. Ma on Stack Overflow See other posts from Stack Overflow or by X. Ma
Published on 2010-04-10T02:58:38Z Indexed on 2010/04/10 3:03 UTC
Read the original article Hit count: 311

Filed under:
|

I'm hesitating between two designs of a database project using Hibernate.

Design #1.

(1) Create a general data provider interface, including a set of DAO interfaces and general data container classes. It hides the underneath implementation. A data provider implementation could access data in database, or an XML file, or a service, or something else. The user of a data provider does not to know about it.

(2) Create a database library with Hibernate. This library implements the data provider interface in (1).

The bad thing about Design #1 is that in order to hide the implementation details, I need to create two sets of data container classes. One in the general data provider interface - let's call them DPI-Objects, the other set is used in the database library, exclusively for entity/attribute mapping in Hibernate - let's call them H-Objects. In the DAO implementation, I need to read data from database to create H-Objects (via Hibernate) and then convert H-Objects into DPI-Objects.

Design #2.

Do not create a general data provider interface. Expose H-Objects directly to components that use the database lib. So the user of the database library needs to be aware of Hibernate.

I like design #1 more, but I don't want to create two sets of data container classes. Is that the right way to hide H-Objects and other Hibernate implementation details from the user who uses the database-based data provider?

Are there any drawbacks of Design #2? I will not implement other data provider in the new future, so should I just forget about the data provider interface and use Design #2?

What do you think about this? Thanks for your time!

© Stack Overflow or respective owner

Related posts about java

Related posts about hibernate