Hi,
If I have a couple of classes like this:
and I have a DAO obj for each, which has store(), update() and delete() methods,
2 questions.
1) If I want to loop thru a group of WidgetPurchase objects, and in order to exist as an object it has to be a part of a purchaseList, so to build the obj I need the id of the Widget, then build that and ALL of its child purchases for every purchase, so theoretically if a Widget has 3 purchcases, the Widget and the purchaseList will be build for all three purchases... in the googling I have done, hibernate does not handle that kind of thing particularly well. Is that correct?
2) when you want to update just the one WidgetPurchase what's the best way of isolating that object?
I suppose you could/should just create the object structure where a purchase can be created in a standalone context, but semantically a WidgetPurchase can't exist without a widget. And in just practical terms when writing web apps, one will typically be passing around db primary keys to be able to build the obj on the server side, correct? Guess I've always held the opinion that loose coupling isn't no coupling, but not sure I'm right about that. Gotta believe this is a pretty common scenario.
thanks!
If I have a couple of classes like this:
and I have a DAO obj for each, which has store(), update() and delete() methods,
2 questions.
1) If I want to loop thru a group of WidgetPurchase objects, and in order to exist as an object it has to be a part of a purchaseList, so to build the obj I need the id of the Widget, then build that and ALL of its child purchases for every purchase, so theoretically if a Widget has 3 purchcases, the Widget and the purchaseList will be build for all three purchases... in the googling I have done, hibernate does not handle that kind of thing particularly well. Is that correct?
2) when you want to update just the one WidgetPurchase what's the best way of isolating that object?
I suppose you could/should just create the object structure where a purchase can be created in a standalone context, but semantically a WidgetPurchase can't exist without a widget. And in just practical terms when writing web apps, one will typically be passing around db primary keys to be able to build the obj on the server side, correct? Guess I've always held the opinion that loose coupling isn't no coupling, but not sure I'm right about that. Gotta believe this is a pretty common scenario.
thanks!