how about bulk updates - the results of editing a lot of records in, say a datagrid?
don't use a gateway but use DAO in a loop instanciating, updating and destroying? and processes? (update...set flg = "N" where flg = "Y" etc ...) I'm just thinking about the overhead instanciating many components just to do something simple thanx barry.b On 7/14/05, Nando <[EMAIL PROTECTED]> wrote: > > Well, in a particular application, there are certainly common things. But as > i said, the primary commonality for me seems to be more in the gateway's > place in the architecture, rather than in the methods themselves. > > Once you know your gateway's place in the architecture, you just put the > methods in there that you need, and add one if the need arises. Some of my > favorites, off the top of my head, might include: > > findAll > findByAlpha (for an alphabetical sort thingy) > findThisProduct > findAllVersions (in case you have versioning ... note that this would be > displayed in the backend actually, but the gateway is still handling the > display layer ...) > findNextN (for a next N interface) > findMe (i use this when i get lost in the internet :) > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, July 13, 2005 9:53 PM > To: [email protected] > Subject: RE: [CFCDev] gateway CFCs > > > > > That's very helpful. So you use Gateways as a means to provide a recordset > that will be consumed by the display layer. That makes sense to me. From > this perspective, they seem like they should be very light weight. > > > > Are there any common "things" that you put into every gateway CFC? Or, are > gateways pretty much customized so there's no commonality from one gateway > to the next? > > > > Tom > > > > ________________________________ > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Nando > Sent: Wednesday, July 13, 2005 2:32 PM > To: [email protected] > Subject: RE: [CFCDev] gateway CFCs > > > > > Hi Tom, > > > > > > Here's another angle on this discussion ... > > > > > > I'm using a gateway to fetch multiple rows or perhaps a single record ... > and usually it's just for the display layer. They are lightweight and easy > to modify. I have a bunch of them in our "flagship" product, they're > instantiated into a manager-type object that's instantiated into application > scope, so they're instantly available when needed to fetch the data for the > display layer. I'm very happy with how that's functioning. Several to many > gateways are called upon to render a display page. > > > > > > DAO's by comparison are involved with editing operations in the admin area > of the app and are used in conjunction with business objects like Person. > They are instantiated every time they are used and then sent to into the > great beyond. Generally, one DAO is used at a time (unless the "thing" i'm > dealing with is composed of more than one business object, then edit > operations use the Parent and Child DAO's in conjunction with the Parent and > Child business objects. > > > > > > I am concerned about performance when it comes to a gateway. I'm not > generally concerned with performance when it comes to a DAO. > > > > > > At first, theoretically, i didn't see much difference between a gateway and > a DAO - they both interact with the database (ok, more correctly, the > data-store). They both have queries in them. They both need the DSN passed > into them. > > > > > > But once i started trying to integrate them into a more sophisticated model, > i saw a very clear difference in their place in the architecture. That's > when i started to understand what a gateway was, at least for myself. > > > > > > :) n. > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, July 13, 2005 3:22 PM > To: [email protected] > Subject: [CFCDev] gateway CFCs > > What are gateway CFCs? What's their purpose? What goes into a gateway CFC? > Is there a best way to construct them? > > > > Thanks - Tom > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > 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' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > 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' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > 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' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > 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' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
