I understand ... Well, in the case of a DAO that handles one row, you have a read() method to populate your BO, right? So that's a 2 way street as well, 1:1 GET and SET. I guess most people populate a BO or a Bean with the read(), and work the validation either in a separate object or within the BO. Then pass the BO into the DAO for the SET.
I still see a possibility for a separate object interfacing with the DB that handles multiple rows - handling both the GET and the SET. It just seems to me from your description that this part of your application essentially functions differently from a BO/Bean-DAO pair that handles one row. The data flow is different, the validation is different, you're probably maintaining state in a different way ... so rather than cluttering up a simple DAO for all that, i'd ponder creating a GriDAO. Don't know where that would bring me, but i'd ponder it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barry Beattie Sent: Thursday, July 14, 2005 7:47 AM To: [email protected] Subject: Re: [CFCDev] gateway CFCs the problem there (hey, my app is mine too!) is that a DAO does all the CRUD routines - including GET. having a gateway as a getter and something else (apart from a DAO within loops) as a setter doesn't feel right - since, in the case of editable datagrids, it's a 1:1 on GET and SET (does that make sence? hope so...) >> if i had an app that did a lot of bulk updating and >> within the architecture I've identified at least a dozen so far, probably more. Their GET criteria (from the users) are VERY dynamic on which fields, etc... round pegs in square holes, perhaps? On 7/14/05, Nando <[EMAIL PROTECTED]> wrote: > > >I think the problem we might be encountering is trying to map everything we > do to a defined Pattern. > > Hmmm ... you know, if i had an app that did a lot of bulk updating and > within the architecture, the DB handling object seemed like it just didn't > fit in as either a DAO or a Gateway, i'd be willing to try making it an > object in it's own right. Gridway, Grateway, GAO, an MDAO - at least i could > try it and see if it fell into place nicely. > > It's My App - TM :) > > > > > > ---------------------------------------------------------- > 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]
