What tier to aggregate data from multiple entities?

[davout]

I have a general question about what tier in an application to create and populate a class that is used to aide GUI presentation requirements. Take the example below...

public class Invoice {
   private String fReference;
   private Date fDate;
   private int fCustomerID;
   private int fCurrencyID;
   private double fAmount;
   ....
   ....
}

public class InvoiceInfo extends Invoice {
   private String fCustomerName;
   private String fCurrencyName;
   ...
   ....
}

public interface InvoiceManager {
   public void add(Invoice aNew);
   public Invoice findByRef(String aRef);
   public Invoice[] findByCustomerID(int aCustomerID);
   public InvoiceInfo findInfoByRef(String aRef);
}

This example has a InvoiceManager service that adds and finds invoices. The links from a invoice to associated entities such as customer and currency are referenced by indirect integer ID's. For this example assume that there are separate underlying tables and manager services for the customer and currency entities.

For read only purposes and to aide presentation efforts I want to include an additional manager call that brings back the invoice info complimented with the currency and customer names, i.e. InvoiceInfo and the 'findInfoByRef'

Is it best practice to have the business tier support this type of method call, or should this work be left to the presentation tier?

Equally if it is the business tier, and I have a separate DAO tier for invoice persistence, should I have an Invoice DAO tier method for 'findInfoByRef' or should the data be assembled in the business tier layer?

In essence the question is when a class aggregates data from multiple persisted entities in what tier should that aggregation effort be located?

Thoughts?

[karldmoore]

It sounds like you are talking about creating a DTO. I wouldn't do it in the service, I'd have something above that layer coverting the objects for you.

[nekoval]

For read only purposes and to aide presentation efforts I want to include an additional manager call that brings back the invoice info complimented with the currency and customer names, i.e. InvoiceInfo and the 'findInfoByRef'

if this aggregation is required for presentation only, I would suggest adding it to Controller or View.

[karldmoore]

if this aggregation is required for presentation only, I would suggest adding it to Controller or View.

Yeah I would agree. When we refactored a legacy system we had to maintain the client interface, this talked DTOs. We didn't really want these coming in or out of the service though so we engineered the existing controller to simply convert between the object types.

[davout]

Many thanks for the responses...

My one concern with the DTO approach is the data retrieval efficiency. In theory I could construct a SQL query that joins the invoice, currency, and customer tables and pull the required data in one call.

Going the DTO route suggests three separate calls, one for the invoice and two follow up calls to the currency and customer data.

Is my understanding correct?

[karldmoore]

I'm not suggesting that you go with a DTO, I thought that's what you were saying you were doing . InvoiceInfo by the looks of it isn't a real object it's just a dumb data holder. If you are working with something like Hibernate you could retrieve you object with it's associations in one go. You can then copy over the state somewhere else. If you are just dealing with SQL you could do the same thing, but it might be easier for you to do this in the Dao.