views:

23

answers:

1

Hi, I need an advice w.r.t. one of the design approach we are considering.

We are implementing a Java web service provider which acts on data in relational database. Our propose classes are:

  1. IDAO - interface with execute() method
  2. GetCustomerDAO and UpdateCustomerDAO implements IDAO
  3. DAOFactory - List of DAO to be reads configuration file which has a mapping of DAOs to be invoked for a particular service.
  4. ServiceImpl - contains getCustomer, updateCustomer methods. The service uses DAOFactory to get list of DAO objects and it then iterates over the list and calls DAO.execute method.

I think it's more of like we have converted DAOs in to Command. However, I don't quite like this approach for some reasons: - In ServiceImpl : you can't influence the flow of DAOs being called. For e.g. after execution of 1st DAO if I don't want to execute 2nd DAO but execute 3rd DAO, it's hard to have this implemented. - besides not sure if we can conceptually use DAO. because a Command object can have business logic, however DAOs should only deal with aspects of reading and writing data to db.

Please let me know your views whether the design looks appropriate. thanks

+2  A: 

I don't see the benefit of using the Command design pattern in this case.
1. The idea with DAO, is to provide an interface that abstract a persistence mechanism. This interface traditionally defines CRUD methods. Each DAO concrete class, would typically implement the DAO interface, for a specific persistence mechanism.For instance, you could have one implementation that stores data into a relational database and another that stores data into an xml file. Both these implementation can be interchangeable since they implement the same inteface.
2. The service functionality can be separated into a separate service layer. Normally, this layer has a dependency on your DAO layer(for persistence). The service interface can be similar to a façade that exposes the business logic implemented in the application (typically, logic in the business layer) to potential clients. Example:
User DAO interface:

public interface UserDao {
    void save(User user);
    void delete(User user);
    void update(User user);
    User findByUsername(String username);
    List findAll();
    ...
}

User Service interface:

public interface UserService {
   void createUser(String username, String password);
   boolean loginUser(String username, String password);
   boolean isUsernameUnique(String username);
   ....
}

Service implementation:

public class UserServiceImpl implements UserService {

  private UserDao userDao;

  public UserServiceImpl(UserDao userDao){
    this.userDao = userDao;
  }
  ...
}
walters
thanks walters. So your suggestion is basically to directly invoke DAO methods within ServiceImpl. I do like that approach.
Rohit
Yep.The Service Layer delegate persistence to the DAO(using Dependency Injection).
walters