Java/Hibernate: Don’t repeat the DAO with a GenericDao

Here, I would like to propose you a good practice concerning the implementation of GenericDao because the basic operations for data persistence are all identical independently of object to save, the methods in question are those of a CRUD: registration (Create), reading (Read), Update (Update) and deletion (Delete).
So, don’t repeat the DAO!!!! in order to increase our code’s productivity due to a GenericDao.

Generic DAO
Following, the steps to implement a generic DAO in ORM system:

Firstly, we need a generic DAO interface which contains the common CRUD available methods, our other specific DAO interfaces must extend it:

These classes and interfaces are built around the best pratices defined in the section HashCode, Equals methods and ORM layer of the post Java/Hibernate: HashCode, Equals methods.
So, our POJO must extend an abstract class with the HashCode, Equals methods overridden in order to compare correctly two objects and containing also a ‘id’ and ‘version’ attributes:

The source code of the GenericDaoImpl and GenericDao interface are in the ZIP file attachement.
This project needs the following librairies commons-beanutils-1.7.0.jar, commons-lang-2.4.jar, commons-logging-1.1.1.jar, hibernate-core-3.3.1.GA.jar, junit-4.1.jar and spring-2.5.5.jar.

Conclusion
A good practice in programming n-tier is to group queries into the service layer. The use of a generic DAO will reduce the number of code’s lines because all standard access methods are available in one class. So, the service layer will contains only the complex methods. More, all queries with HQL queries will be grouped in a single service object that corresponds to a domain object representing a module.