> 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.
If an exception is raised inside a transaction, it will automatically roll back, with no explicit help from you, but the exception will not be handled. In other words, CF will take care of rolling back the transaction for you, and still propogate the error up to your exception handling mechanism for you to do what you will. We also use exceptions from the lower levels to control execution (good practice, IMHO), but the question still remains where to put the CFTRANSACTION tag. Since the definition of a given transaction is part of the business rules for the entities being manipulated, I say it belongs in the business logic. It'll have to be at a high level, because it potentially needs to "oversee" multiple actions, on multiple types of entities. Putting the CFTRANSACTION tag in the controller makes some sense (that's where we used to do it), because it's directly above the entity-level business logic (the same place the services layer would be). However, as soon as you started exposing parts of your application via web services, flash remoting, or whatever, you may be using a different controller setup, and therefore have to duplicate all that transaction logic in the new controller. By pulling it out of the controller into a services tier, you can reuse the transaction logic with whatever controller you want. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Curtis > Sent: Thursday, June 17, 2004 10:36 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] encapsulating transactions, WAS: Nested > cftransaction error in CFMX 6.1 > > > > 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. > ---------------------------------------------------------- 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]
