DAO design pattern

[alex.p]

I'm just embarking on a new project and I'm kind of new to the hibernate/spring integration side of things and was just wondering what the best DAO design pattern would be that would suit hibernate integration.

At the moment I'm thinking DAO interface for each domain object and then inherit from that as HibernateDAO along with subclassing the HibernateDAOSupport class.

One thing I don't know is that I noticed that the domain objects produced from the DAO all have mutators and accessors on them so that Hibernate can access their properties to persist them but what happens if I want to keep the properties of my domain objects encapsulated? Should I put a wrapper around the entities and make that be the true domain object?

Any help or guidance would be appreciated a lot! Thanks for your time.

[dr_pompeii]

Hello

Take a look here
So should you still use Spring's HibernateTemplate and/or JpaTemplate??

Normally for each class or entity I create its own DAO class with the CRUD methods, save, create, find, etc, of course each class must implement its own interface since Spring work strongly with the Proxy Pattern

[alex.p]

Ah thanks but for each entity does that entity hold business logic - like a domain object or does it simply have getters and setters for each field and the domain object wraps around it?

[dr_pompeii]

I work in this way

An Entity has basically its:

• constructor
• setter/getters accessors methods
• toString method
• add/remove methods to add/remove an element from a Collection (for example the Set collection to add or remove a Child)

lets call for example Customer to some Entity

Therefore the MVC architecture/pattern should be (a general idea - some terms or semantics could vary slightly)

CustomerController-->CustomerBO-->CustomerDAO-->Customer

CustomerBO Should has the Business methods
CustomerDAO must has only the CRUD methods

I suggest you read more about the MVC, without a clear understanding of this important architecture you would do a bad application

[alex.p]

Ah thanks so from my understanding the CustomerController and the CustomerBO is the controller, the CustomerDAO and the Customer represents the model and any GUI stuff like panels and dialogs would be the view.

[ajans]

Hibernate's goal is to relieve the developer from 95 percent of common data persistence related programming tasks. Hibernate may not be the best solution for data-centric applications that only use stored-procedures to implement the business logic in the database, it is most useful with object-oriented domain models and business logic in the Java-based middle-tier. However, Hibernate can certainly help you to remove or encapsulate vendor-specific SQL code and will help with the common task of result set translation from a tabular representation to a graph of objects.

[alex.p]

Hibernate's goal is to relieve the developer from 95 percent of common data persistence related programming tasks. Hibernate may not be the best solution for data-centric applications that only use stored-procedures to implement the business logic in the database, it is most useful with object-oriented domain models and business logic in the Java-based middle-tier. However, Hibernate can certainly help you to remove or encapsulate vendor-specific SQL code and will help with the common task of result set translation from a tabular representation to a graph of objects.

Why have you copy and pasted paragraph 3 of http://docs.jboss.org/hibernate/core...l/preface.html ? It has no relevance other than the fact it's related to Hibernate.