Not a touchy-feely philosophy on how to intuit your way through junk. The DAO of CRUD might be an encapsulation problem; it might be I'm new to this and am missing something.
I'm reading the Mach II devguide at macromedia, and in the Data Access Object section it refers to CRUD functions (Create, Read, Update, Destroy).
It seems to me that unless the DAO binds the two actions Create and Update into one method then the rest of the object (the non-DAO bits) need to know if the object has previously been saved to determine if Create or Update should be used. But the concern of "previously been saved" should be confined to the DAO in order to properly encapsulate it--that way, the DAO can persist the data in any way it cares to, without the rest of the Object interfering. For example, the unique identifier could be blank for new data but for the saved data it could be an integer (PK in a single DB table), a UUID (saved as a file), a comma-delimited series of integers (multiple db tables), a variable reference to an array or struct (stored in RAM - not *really* persistant...), and so forth. And only the DAO should read or write or validate it.
So what I'm thinking is that the Object might create a DAO_ID property, but only the DAO can read or write to it--ideally, the DAO would create it, but then properties are being created outside of init(), which feels dirty. If the rest of the Object needs to know if the data are new or previously-saved, then that itself is a property and not derived from the existance of an ID (common for stuff read from DBs, yes?). If the Object needs to set defaults for a new/non-previously-saved Object, then it passes these values to the DAO.
Since this isn't how http://livedocs.macromedia.com/wtg/public/machiidevguide/articledao.cfc.txt seems to be set up, I'm thinking either I'm missing something, what I'm suggesting is unduly difficult, or it's just one of those things, you know?
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: 310 478 6648
f: 310 235 2067----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
