assembling an object graph without an ORM -- in the service layer or data layer?

Question

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