Modeling--DAO vs ORM

Question

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.

Answer 1

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...No, I wouldn't do it that way. I don't write a DAO for every object. If there are child/parent relationships, and the child doesn't have a sensible life without the parent, then I just write a parent DAO.
I don't know about Purchases, but I can see an Order object with child LineItems. A LineItem doesn't make much sense outside its Order parent, so in that case I'd have an OrderDAO that would maintain the relationship and get all the children for me. I never query directly for the LineItems.
Your way of doing things is too database centric. It's the kind of thing I see from people who are used to client/server and going right to the table for every scrap of data they want. It tends to result in a "chatty" model ("OK, first I get this column from the table; now I want this one....") I've see some misguided DAOs that were written this way. One call resulted in 80 data roundtrips. Can you say "non-performant"?
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.Nope, now you're guilty of letting a misunderstanding of patterns dictate your design. What's worse?
I agree that the relational and object models should not be one-to-one, since there are features of O-O that have no direct analog in the relational model. But they are related, and they do mimic each other to some degree. After all, they are modeling the same problem.
%