>>Whew, I hope I'm not rambling. not at all. thanx Bill and Nando. makes much more sence now for dealing with these bulk data jobs.
cheers barry.b On 7/14/05, Bill Rawlinson <[EMAIL PROTECTED]> wrote: > I think Nando's view of a Gateway is right on track with Fowlers basic > definition. It provides an API of sorts to get the data that needs to > be displayed. He has one place to get it from for a certain subset of > data. > > I think the problem we might be encountering is trying to map > everything we do to a defined Pattern. Barry, your desire to place > all of the stuff that does bulk processing on on a specific dataset in > one object makes perfect sense as well. This would probably be in the > spirit of how Gateways are often talked about on this list. DAO for > single rows, Gateways for many. > > There really is very little difference in what you are both talking > about, as far as I can tell. > > Nando's gateway just reads data, while yours, Barry, would write as > well. In both regards neither object has to do any validation > specifically. Barry could pass his big collection of data that will > be written to a validation object first. This validation object could > then loop over the collection, figure out what is good and bad, and > either split it up into two collections (good and bad) or pass back > the whole thing with associated errors for each item in the > collection. If the validator passed back two collections (if that is > OK with your systems rules) then you could bulk update/save the good > collection and pass back the bad for further processing/manipulation > by the user. Else you could put a hold on all saving/updating until > the entire initial collection is good. > > Either way your business layer is taking care of all this validation > and passing it back to your view and or passing it on to your > persistance layer. > > Either way I think your Gateway (be it a readonly type of thing or one > that also writes/deletes) is doing one thing, and doing it well. It > is processing collections of data and serving as an interface to your > persistance layer. > > Whew, I hope I'm not rambling. I am tired, and I had my but handed to > me in the designer developer poker tourny tonight, so I need to get > some sleep. > > Cheers, > Bill > > On 7/13/05, Barry Beattie <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > -- > [EMAIL PROTECTED] > http://blog.rawlinson.us > > If you want Gmail - just ask. > > > ---------------------------------------------------------- > 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]
