In my way of thinking, transactions are a pure business logic "thing", they have nothing to do with persistance (though that's where they're actually implemented).
Although I'm not sure about this (is data integrity really part of business logic?), I like your thinking and the model code you showed us matches something I've had in the back of my mind for a while.
You will need to expose a means for starting, committing and rolling back a transaction to your business components from your persistence components. However, the persistance components' other methods shouldn't be aware that they exist, they're only there for the use of the business logic components.
busnessLogic.cfc: function myMethod() { persister.startTransaction(); persister.updateItem(); persister.updateOtherItem(); var i = persister.checkThing(); if (NOT i) { persister.rollbackTransaction(); } else { persister.updateFinalItem(); persister.commitTransaction(); } }
Do you imagine this code using <cftransaction> or setting up the transactions directly in the SQL?
There have been a couple discussions here about persistence components, but I'm not quite sure I ever understood them or how to code them or why to use them. Could you point me in the right direction? Something to read, online or off?
--
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 word '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]
