All transactions are defined in my service layer components, IN PUBLIC
METHODS. Since all requests to the persistance layer have to go through the
service layer, that assures that transactions can be applied consistently
and completely in that single strata.
Nice solution, Barney. I've been thinking about this sort of thing recently, myself. However, I was considering putting the cftransactions outside the model, into the controller(s). You state:
This type of organization makes far more sense than putting CFTRANSACTION
tags in your persistance layer, IMHO. Transactions are really a
business-logic concern; they have nothing to do with storing anything,
rather they ensure that your stored data is never in a state that violates
business rules.
I have been seeing cftransaction as error handling, because it allows you to test for an error and clean it up if need be. Our business model is designed to throw errors to the next level up (it also may do its own thing, such as logging, but the application handles the error higher up the stream). Therefore we have been thinking about putting the cftransaction alongside our try/catch blocks in the controllers.
I'd like to hear if I'm off my rocker on this one.
--
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]
