thanx guys see, that's my point: you start off thinking "this is just simple CRUD stuff", a new requirement comes in and the next thing you know you're refactoring a ton of code and retesting it all... just because of transactions and the inability to nest them.
On 10/27/07, Brian Kotek <[EMAIL PROTECTED]> wrote: > +1 for Service layer as the place to manage transactions that span multiple > domain objects, or multiple kinds of domain objects. > > > On 10/26/07, Alan Livie <[EMAIL PROTECTED]> wrote: > > > > I think a service layer is a good place for managing transactions (as > others have suggested on this list). > > > > A DAO is good until you need to manage a transaction where more than one > object is involved (ie an OrderItemDAO and a TransactionDAO). > > > > In this example you could have a method in the service layer createOrder() > that begins the transaction, calls methods on all the objects it needs then > closes the transaction. > > > > > > Alan > > > > > > ________________________________________ > > From: [email protected] [EMAIL PROTECTED] On Behalf Of Barry > Beattie [EMAIL PROTECTED] ] > > Sent: 26 October 2007 07:23 > > To: [email protected] > > Subject: [CFCDEV] where to put transactions? > > > > Where to put transactions - I've been down this path before with mixed > > results - never been 100% happy. > > > > Previously I've used wrapper transaction functions so I had a choice > > how I wanted methods called, etc. Or I've moved the transactions > > further and further up the calling stack. > > > > > > with this example (below) ideally this should be done deep in the > > database .... but I haven't that luxury in this case. > > > > what I'll have grief with is that the "gwEval.save(dtoEval);" already > > has a transaction so it'll get the correct PKey to return on the > > insert. And this is just a simple example. > > > > (NOTE: this uses anemic beans and DAO's while all my gateways are > > really for Flash Remoting, not specifically query/multiple record > > CFC's.) > > > > it's the gwEval.getByFields > > not finding one > > returning an empty bean > > and gwEval.save(dtoEval) saving the bean. > > > > I'm reluctant to move all that deep into the DAO because either I have > > to refer to the other object for that FKey value within the DAO or > > pass it in (which means I may be getting it for no reason) > > > > it's not a show-stopper - it's just I don't like any of the solutions > > I've come up with so far... > > > > thoughts? > > thanx > > barry.b > > > > > > <cfset gwEval = > createObject("component","components._evalGateway") /> > > > > <!--- START A TRANSACTION HERE (hopes) -----------> > > > > <cfset dtoEval = gwEval.getByFields(courseID="#courseID#", > > modID="#modID#").init() /> > > <cfif len(dtoEval.getevalID()) EQ 0 or dtoEval.getevalID() EQ 0> > > <!--- empty/doesn't exist yet ---> > > <!--- get the default evaluation instrument (needed for a FKey) > ---> > > <cfset dtoInst = > > > createObject("component","components._instGateway").getByDefault() > /> > > <cfscript> > > dtoInst.init(); > > dtoEval.setEvalID(0); // the flag for "create" > > dtoEval.setmodID(modID); > > dtoEval.setcourseID (courseID); > > dtoEval.setstartdate(now()); > > dtoEval.setinstID(dtoInst.getInstID()); > > dtoEval.setevalname("Evaluation For " & modID); > > dtoEval.setactive(1); > > gwEval.save(dtoEval); /*** has TRANS deep inside > ***/ > > </cfscript> > > </cfif> > > <!--- at this stage, dtoEval should be either fully populated with > > existing data or created from default values ---> > > > > <!--- END TRANSACTION HERE (hopes) -----------> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
