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

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.