Rohit Agrawal

Greenhorn
+ Follow
since Apr 10, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rohit Agrawal

thanks Eduardo . I do have some good points of why you may want to split DAO classes.

Typically I have seen DAOs that does various operations - create, delete, update, etc. Depending on the complexity of the underling business entity it's dealing with, the DAO class tend to become huge (>800LOC) over time or right away. Hence I like to split the DAO class, one each for every operation on the entity. This helps in maintenance and ease of understanding.

I am also considering another approach of simply using DAOFactory and invoking DAOs at runtime as per business logic. e.g.
IDAO dao = DAOFactory.getDAO('GetCustomerDAO')
ResultHolder rh = dao.execute();
CustomerData cd = rh.getCustomerData();
...do some processing
if (cd.status='Active') {
//calculate next review date;
IDAO dao2 = DAOFactory.getDAO('UpdateCustomerDAO')
ResultHolder rh = dao.execute('reviewdate');
}
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