assembling an object graph without an ORM -- in the service layer or data layer?
- by Hans Gruber
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"?
