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.
We've been creating Factory/Singletons for each of the DAO, Gateway's, etc. While perhaps slightly quicker because objects are cached and reused, the much larger benefit is that construction of objects has been abstracted. No object needs to know how to create an object, where it is located, etc. As our package layout has changed periodically, this has been invaluable.
The two patterns together also allow for interesting Abstract Factory patterns, as described elsewhere. We can pass in different DSNs depending upon conditions in the calling application, different data sources, etc. For example, occasionally we get employee data out of a LDAP instead of a RDBMS.
Chris
--
*********************** Chris Dempsey Director, Information Services UCSB Graduate Division Quidquid latine dictum sit, altum videtur.
---------------------------------------------------------- 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]
