At my current gig, our persistence layer uses IBatis going against SQL Server stored procedures (puke). IMHO, this approach has many disadvantages over
the use of a "true" ORM such NHibernate or EF, but
the one I'm trying to address here revolves around all
the boilerplate code needed to map data from a result set into an object
graph.
Say I have
the following DTO object
graph I want to return to my presentation layer:
IEnumerable<CustomerDTO>
|--> IEnumerable<AddressDTO>
|--> LatestOrderDTO
The way I've implemented this is to have a discrete method in my DAO class to return each IEnumerable<*DTO>, and then have my service class be responsible for orchestrating
the calls to
the DAO. It then returns
the fully assembled object
graph to
the client:
public class SomeService(){
public SomeService(IDao someDao){
this._someDao = someDao;
}
public IEnumerable<CustomerDTO> ListCustomersForHistory(int brokerId){
var customers = _someDao.ListCustomersForBroker(brokerId);
foreach (customer in customers){
customer.Addresses = someDao.ListCustomersAddresses(brokerId);
customer.LatestOrder = someDao.GetCustomerLatestOrder(brokerId);
}
}
return customers;
}
My question is should this logic belong in
the service layer or
the should I make my DAO such that it instead returns
the assembled object
graph. If I was using NHibernate, I assume that this kind of relationship association between objects comes for "free"?
