Your DAO implements a persistance mechanism. There's no need to tell it how to use the mechanism it implements. It's the job of the manager/service/listener object to tell the DAO what to do, and pass it an appropriate BO to do it on/with/to.
For instance, if a DAO used the existance of the primary key to decided if "persist" method needed to insert or update, then you'd be limiting how the manager can use the DAO. If you just have insert and update methods, then the manager can read a BO, and then immediately call DAO.create on that BO to have it duplicated in the DB. The DAO shouldn't care if that happens, because that's a business logic concern, not a data access concern. DAO should really be nothing more than parameterized SQL statements, unless the persistance mechanism requires more logic (XML files, for example). Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Curtis > Sent: Wednesday, February 04, 2004 2:38 PM > To: cfcdev > Subject: [CFCDev] The DAO of CRUD > > > 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/artic > ledao.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] > ---------------------------------------------------------- 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]
