About Data Objects and DAO Design Using Hibernate
I am hesitating between two database project projects using Hibernate.
Construction number 1.
(1) Create a generic data provider interface including a set of DAOs and shared data container classes. It hides the bottom implementation. A data provider implementation can access data in a database or an XML file or a service or something else. The data provider user is unaware of this.
(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 generic data provider interface - let's call their DPI objects, the other set is used in the database library, exclusively for entity / attribute mapping in Hibernate - call them H-Objects. In DAO implementation, I need to read data from the database to create H objects (via Hibernate) and then convert H objects to DPI objects.
Design No. 2.
Don't create a generic data provider interface. Export H objects directly to components that use the lib database. Therefore, the user of the database library must know Hibernate.
I like design # 1, but I don't want to create two sets of data container classes. Is this the correct way to hide H and other Hibernate object data from the user who is using the database data provider?
Are there design flaws # 2? I won't be implementing another 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? Thank you for your time!
source to share
I highly recommend reading Chapter 4, "Starting a Database" of Spring in Action, 3rd Edition , even if you are not using Spring in your application. Although my second recommendation would be to use Spring :-)
The DAO pattern is a great way to isolate your database and ORM logic in your DAO implementation, and you only need one set of entity objects. You can do it without Spring, you just need to work harder on your sessions and transactions.
If I understand your post, this is sort of a middle ground between design 1 and design 2. H-Objects (objects that Hibernates are loaded and persisted) don't need any special Hibernate code at all. This makes them perfectly acceptable for use as DPI objects.
I have had arguments with people in the past who complain that using JPA or Hibernate Annotations exposes Hibernate features through the DAO interface.I personally take a more pragmatic view, since annotations are just metadata and do not directly affect how your entity classes work.
If you feel like annotations are pushing too much, you can go the old school and use Hibernate Mappings instead . Then your H-objects are 100% free with no hibernation :-)
source to share
I recommend design # 2. Just create domain objects and let hibernate keep track of them. Do not write down individual classes that are saved.
Hibernate tries to hide much of the business of persistence. You may need to add some small annotations to your organizations to help them. But, of course, don't make separate classes.
You may need very small DAO classes. For example, if you have a Person object, it would be fairly common practice to have a PersonDAO object that stores the person. Having said that, the code inside the DAO will be very simple, so for a really small project it might not be worth it. For a large project, it is probably worth keeping the persistence code separate from your business logic if you want to use a different persistence technology later.
source to share