Transactions are a business logic concept, not a persistance concept, even though they're usually bound to the actual persistant store (the database). Assuming your business logic resides in your service objects, each method call to a service should be a single encapsulated business operation, and consequently a transaction. If you're business logic is in your presenter, then putting your transactions there is the correct thing to do, though I'd recommend separating the business logic out form the presentation logic, so that you can vary and reuse each part independantly.
It's entirely possible that a single page request makes several calls to the services, but each one should be independant. For example (shopping app), you might need to retrieve user information and update their hit count, pull a list of shopping cart items, and pull a list of items in the category the user's looking at. One page, three separate operations, three separate method calls to the services, three separate transactions. cheers, barneyb On Tue, 03 Aug 2004 03:03:56 -0500, Barry L Beattie <[EMAIL PROTECTED]> wrote: > Hi all > > we're building a MVP-type app (with touches of MVC and Spike's BATFINK) that is > module based (user mgt, account mgt, products, etc). > > each module has a dedicated persist and service CFC's with an over-riding presenter > CFC that puts it all together and receives form/url data > > - persist - the DataAccessLayer > - service - glue between presenter and persist (data validation, package of data, > etc) > - presenter - contains page and user logic that binds data to the taglib to form > views > > the service and persist have atomic methods that are re-used widely > - AddNewProduct > - AddNewProductNotes > - AddNewMerchant > > with such atomic methods, we're finding the best place to control transactions is > not in the persist but in the presenter. > > is this sheer madness or perfectly legit? > > I've run it up and it seems to work (provided the presenter's method creates the > service which creates the persist) > > the only thing I can think is not good is the constant creation and destruction of > service and persist objects (performance hit) which also means that they can't be > stored in server scope with the presenter. > > any thoughts? > thanx > barry.b ---------------------------------------------------------- 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]
