Data integrity is definitely a business logic concern. The persistance layer only cares about type validity (int, decimal, string, etc), it should have no knowledge of what a given piece of data actually means, or whether it needs to be kept in sync with some other piece of data (which is an even higher-level concern).
As for the xxTransaction() methods, that choice is entirely up to the implementer of the persistance component. I'd just use CFTRANSACTION tags with the ACTION attribute (and probably have the isolation level provided to the components constructor), but you can do it however you want. I could also potentially see a need to not use a transaction-capable storage mechanism, either a underfeatured DBMS, or perhaps flat files (XML, CVS, whatever) for a low-load but highly-portable app. Then the xxTransaction() methods would probably use CFLOCK, or perhaps non-transactional locking provided by the DBMS (such as LOCK TABLE for MyISAM tables in MySQL). In any of these situations, the business logic components needn't change at all, and that's the reason encapsulation kicks so much ass. cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Ben Curtis > Sent: Tuesday, November 18, 2003 11:55 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] cftransactions in low level modules > > > > > 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] > ---------------------------------------------------------- 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]
