Yeah -- that part I got. I guess the complications started when I wanted my 'business tier' to use other methods of the business tier. Simple example: Create a new user -- at the business layer this is a transaction that inserts records into a user table as well as ancillary tables, such as preferences, etc. But, then you might have some other process that also involves creating a user, and it would be nice to just use the create user method, but if my other process also wants to be a transaction you end up with problems (And with needing to know about implementation details of your createUser() method). In other words, the problem crops up when you want to use peer methods (peer in terms of tier). But, it sounds like the solution is really to just reuse some of the persistence methods in the business tier, so that each transaction is self-contained, rather than reusing other parts of the API -- though, Barney's approach of using package methods in that way makes a lot of sense as an even better way to avoid the redundant code.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sean Corfield > Sent: Thursday, June 17, 2004 11:34 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] encapsulating transactions, WAS: Nested > cftransaction error in CFMX 6.1 > > > On Thu, 17 Jun 2004 08:41:12 -0700, Nathan Dintenfass > <[EMAIL PROTECTED]> wrote: > > Sean, you say such nested transactions were "bugs" in your code > -- but, I > > suspect at least some of those were due to people following good > > encapsulation rules > > Barney's response is spot on: transactions are business layer concepts > so the "bugs" in our code were where we had mixed responsibilities > across tiers. Designing transactions into your business model is right > up there with designing exceptions into your application - it's not > easy but it's very important to get it right. It's all about putting > the right responsibilities into the right pieces of code. > > Nathan, you talked about having to refactor - that's right: you need > to separate transactions out from the lower level database > interactions. Barney's "dual method" approach solves that quite > neatly. > > Some people feel that such separation is overkill but it's the > separation that helps us really understand our applications and makes > enhancements easier. Coherence: each thing should do one > self-contained task (and do it well). > -- > Sean A Corfield -- http://www.corfield.org/blog/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > ---------------------------------------------------------- > 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] > ---------------------------------------------------------- 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]
