modeling--DAO vs ORM

[Tom]

Hi, quick question about accessing the persistence layer, in particular
using DAO vs. using ORM. Let's say I have a Customer class which has a 1:N
relationship to his purchases, so for ORM, I would do something like this:

class Customer {
int id;
List<Purchase> purchases;
// also include all the usual, firsname, lastname, etc
int getId();
setId();
List getPurchases();
setPurchases();
}

class Purchase {
int id;
// purchaseName, date, etc...

setId();
int getId();

}

So to get the purchases for a particular customer, using ORM, I would so
something like:
Customer c = ORMManager.load(c, customerid);
then I would do
List p = c.getPurchases();
to get the purchases.

Now, for the DAO pattern, I would do this instead:
List p = PurchasesDAO.getPurchasesByCustomer(customerid);
so then I would not even need a reference to the list of purchases in the
Customer class...

SO, my question is, it seems to me that the persistence layer should not
dictate the modelling of the business objects, yet this seems to contradict
that. What would you suggest? If using the DAO pattern it seems like all
business objects would have no references to any other business objects.

-Tom

 

[Alan Krueger]

Now, for the DAO pattern, I would do this instead:
List p = PurchasesDAO.getPurchasesByCustomer(customerid);
so then I would not even need a reference to the list of purchases in the
Customer class...

I've seen DTOs that essentially did this: (greatly simplified for
example's sake)

public class Customer {
String customerID;
CustomerDAO createdBy;

public List getPurchases() {
PurchasesDAO pdao = createdBy.getFactory().getPurchasesDAO();
return pdao.getPurchasesByCustomer(customerID);
}
}

I don't recall anything in the DAO pattern that prohibits this.

(Setting follow-ups.)