>so, by abstracting the persist/data layer in this way, how are you able to deal with transactions - esp with multiple tables (and therefore multiple CFC's)?
We're not dogmatic about "a CFC only deals with one table". What we've done is more from the POV of removing the user's (in this case a developer) need to understand or care about the underlying database storage methods. So we might have a package of CFCs that relate to "user permissions", which might have a CFC each for "users" and "usergroups" (it's more complex than that in reality, natch, but I've simplified it by way of example). Each of these two CFCs does have basic get(), add(), delete(), update() methods that map directly to the single table. But then has more task-oriented methods like createNewSystemUser(), which might do a bunch of stuff like create a new user record, add that record to the "Everyone" group, assign some base permissions, and that sort of palarver. What we try *not* to do is to step outset the realms of the package when creating these functions. For argument's sake when a user is created, we add a record to the audit trail: we don't have a <cfquery>insert into audit_trail</cfquery>, we use the add() method of the audit_trail CFC. Adam ---------------------------------------------------------- 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]
