What is the pros and cons of using Generic DAO and Generic Service Pattern in Spring MVC with Hibernate

Question

I have a thought to implement Generic DAO and Generic Service in my new project. I have seen lot of examples in the web.

Before start I want to know the pros and cons of using this design pattern.

Can any one tell Is it advisable to use this pattern?

Answer 1

I think, it will be better to have an other opinion about DAO and generic DAO. Some words about Pros (My suggestions are valid if you use ORM, Hibernate for an example, not plain JDBC).

1. Creates a nice abstraction layer of the actual storage system.

It is a marketing bullshit. In real life we have problems to migrate between various RDBMS (Oracle RDBMS -> PostgreSQL). Not speaking about change of a storage system type (RDBMS -> NoSQL for example).

2. Provide a more object-oriented view of the persistence layer.

No! It is very hard to do properly. Most DAO implementations have a dozens of methods like

getSomething(String x, String y, String z);
getSomethingOther(String x, String z); 

3. Provide a clean separation between the domain class and code which will perform the data access from databse.[using JDBC,ORM[like hibernate] or JPA].

May be, but usefulness of this separation is exaggerated.

4. Once you have the general CRUD flow set, the same layout can be repeated for other DAOs.

It is correct.

Answer 2

Generic DAO design pattern comes into picture when more then one DAO classes wants to communicate with database (as per example CRUD(Create,Read ,Update and Delete) ),with out this design pattern you will end up writing separate code to make database call (using session) for each of your DAO classes which is a tedious work in general because with each new implementation of DAO classes you have to write you own code to deal with database.

Below are some Pros and cons of using Generic DAO.

Note: Details give below are what I have learned from answers given to SO Question Pros and Cons of the use of DAO pattern

Pros

1. Creates a nice abstraction layer of the actual storage system.

2. Provide a more object-oriented view of the persistence layer .

3. Provide a clean separation between the domain class and code which will perform the data access from databse.[using JDBC,ORM[like hibernate] or JPA]

4. Once you have the general CRUD flow set, the same layout can be repeated for other DAOs.

Cons

1. If you handwrite the DAOs, then the code can become tedious and repetitive you have to use code generators/templates and ORM.

Q - Can any one tell Is it advisable to use this pattern?

A- After Observing above pros and cons I used Generic DAO in my application as abstraction layer to communicate with database in Terms Of CRUD which actual helped me reduces lots of duplicate code to do same thing other DAOs.At first it will take time to get used to it of afterwards use of Generic DAO will make you life easy.