generic dao architecture discuss-best prastice

Question

i thinking of doing this architecture

genericdao +interface ---> servicelayer+interface---> view layer

my dao will only have generic methods, my service layers will have real logic for instance

service layer method

string executeThis= "select c from com.abc.test.User where username =:username";
Map tempMap = new HashMap();
tempMap.put("username","abc");
return callDaoInferface.executeGenericList(executeThis,tempMap);   //get from DI

Do you this this is good architecture

my question is whether suitable to move the "select.." statement from dao into service layer

Answer 1

Not really, no. What is the 'tempMap' doing? It seems a little weird.

Answer 2

Your use of interfaces is pretty much the way Spring does it, whether or not you use generic DAOs. It includes the web tier as part of the view.

I'm not crazy about your service code. The whole point of the persistence interface is to abstract SQL away from clients, yet you've let SELECT leak into your service layer. Wrong, in my opinion.

There's little or nothing object-oriented about the way you're doing things.

I'm assuming that "generic dao" means something like this.

I've done it with Spring and Hibernate. The generic DAO interface looked like this:

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    List<T> find();
    T find(K id);
    List<T> find(T example);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

So if I have User and Book model objects, I might have two DAOs like this:

GenericDao<User, Long> userDao = new GenericDaoImpl<User, Long>(User.class);
GenericDao<Book, String> bookDao = new GenericDaoImpl<Book, String>(Book.class);

The GenericDaoImpl is either an exercise for you or will have to wait until I can post the source code.

Answer 3

Your architecture is just a little off.

You want a dao interface to abstract succinct db interactions, or in other words, you could implement the data access contract with various implementations, such as JPA, Hibernate, Oracle, JDBC, etc. Your queries should reside with the implementation, and you should look into named queries, which I know exists in Hibernate and JPA. Queries could be different based upon the implementation, such as db specific nuances (like MySQL's 'limit') or HQL (Hibernate Query Language) vs. SQL.

In my opinion, a service layer in most instances (like this one) is simply overhead. You would want a service for something like user authorization, where your service layer might perform some business logic to properly construct the lookup. For example, you might need to encrypt/decrypt a password, or verify that a username doesn't already exists, minimum password requirement satisfaction, etc.

Duffy's generic DAO example is pretty much the standard and I would suggest implementing a variation of that...e.g. UserDaoHibernateImpl extends GenericDao<User, Long>