Well, first, i wouldn't place my DAO's in application scope - i'd just instantiate them as needed and let them die.
Second, i think i would find it a LOT easier to use a separate DAO for the subObject, in your example, Floor. Whether or not to use a persist() method within HotelDAO as in my example probably depends ... in the app i took the example from, both Hotel and Floor would be updated at the same time, so it made sense for me to do it this way. Generally speaking, for performance sake, i can certainly see caching a DG - a data gateway in Application scope. But since create, update and delete operations are much more rare, i'd rather create a unique instance for every operation. That's one of the advantages of separating your DG's from your DAO's, IMHO. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 8:10 PM To: [email protected] Subject: Re: [CFCDev] While we're on the subject of DAOs Ok this got way outta hand. Maybe I shouldn't have framed that example in that way. My question came down to this: If I have an object composed of a collection of other objects (an array of them) and those composition objects have no existence outside the main object, should I use the main object's DAO to persist the collection directly or should those other objects have their own persistence objects (DAOs)? The answer I received in the example previously provided was that it was probably best to have the main object's DAO loop over and call each of the sub object's DAO individually. Forgetting all the sidebars of rooms and ballrooms etc, User loads Hotel object which is composed of floor objects User makes a change to attributes on floor #5 User saves changes Application calls application.HotelDAO to persist the hotel application.HotelDAO loops over the floor objects and identifies if there was a change, if so it calls application.FloorDAO to persist the change to that floor. Everybody ok with that? Jason Cronk [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
