thanx Nando I suppose if gateways just fetched data and provided various views then the gateways are essentially an API to that data (and where I was going to with the caching bit). Simple (and the "one thing done well").
but then the idea of adding/updating/deleting bulk data comes up and if it's NOT using DAO's (and looping over them one at a time) then what to do? If it's by a gateway then it's akin to an updatable view, yes? is that (DML-type actions) really a job for a gateway or an entirely new animal? > But hey, i'm new at this! you're not on your own, there... thanx barry.b On 7/14/05, Nando <[EMAIL PROTECTED]> wrote: > I guess here the line between a DAO and a gateway is a little blurred for > me. > > The OO principle is at work here is cohesion, do one thing and do it well. > Cohesion makes a lot of sense, of course, but the problem is always how to > decide WHAT that thing is. What criteria do you base your decision on? > > Does that "one thing to do well" look more like this? > > DAO - handles the database interaction for a single articles / Gateway - > handles the database interaction for articles? > > or like this? > > DAO - handles the database interaction for cases where you modify what's > persisted (in the database) - if the interaction is in and out from the > datastore / Gateway - handles fetching records for display and doesn't > usually tangle with a business object - out only from the datastore. > > My feeling is more toward the second, simply because it seems to me like the > "Do one thing and do it well" principle has more to do with an object's role > within an application and less to do with how it accomplishes it's task - > the specifics of implementation. Put the operative words "Do ... do it well" > in the hands of a programmer and our tendency is to think toward > implementation, toward the how rather than the role. > > But hey, i'm new at this! > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Barry Beattie > Sent: Thursday, July 14, 2005 1:21 AM > To: [email protected] > Subject: Re: [CFCDev] gateway CFCs > > > 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] > > > > > > > ---------------------------------------------------------- > 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]
