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"?