This conversation reminds me of Seminary. (That is where I met my wife.) There were all kinds of guys wrapped up in getting the terminology right who couldn't answer basic questions of life. You would ask them questions with simple answers... like "Where did Cain get his wife?" and they would go blank! Even worse... they might lead of into a discussion of the hermeneutical considerations of the ecclesiastical implications were a person to pontificate on the broader considerations of the subject. Other guy would say... what? That would of course only consider them to ramble on in terms that among piers would make them feel like knowing the language and the theological implications taught them about life. Then they would talk about this other person who they greatly admired... and explain how next to that person they knew nothing. (Which in part you could become to believe.) Yet, then you found out that the reference actually positioned them as being the greater and you and I the lesser.
Now the guys directly in this conversation I don't know to be of that bent... but even in this thread the same empty answers has been given. It's more a discussion of terminology than application. Guys... what is most important isn't the term... but the way to do what you are saying. In fact it would be good to create a lexicon of terms on the site this list is from. Then we could reference people to definitions and examples and spend our time here discussing how to, and why we do. </rant> -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Thursday, September 15, 2005 3:35 PM To: [email protected] Subject: RE: [CFCDev] Table joins DAOs Joe, Sound like you might simply need an order gateway. (of course, you CAN put everything in one object, but i dn't like doing that. i like cohesive do one thing well objects much better. easier to work with, and leaves your app more flexible) Here's how i differentiate them. DAO's work with corresponding BO's and forms to modify and create and delete stuff. Gateways are more lightweight. They are generally for returning queries to the display, and occupy a different place/function in your model. JOIN away in your Gateways, whatever you need to create reports / display information. There's a grey area inbetween. Sometimes you might create a process where you'd automatically update a bunch of records. From what i hear, people tend to put the grey area stuff in gateways. n. :) > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Joe Ferraro > Sent: Thursday, September 15, 2005 9:20 PM > To: [email protected] > Subject: RE: [CFCDev] Table joins DAOs > > > Ok here is the example I have and I could really use community input. > > I have orders and orders have order products > > I need to find all the products of an order which has the status of > backorder > > Now I can see where you might say create an order DAO that joins the order > and products table, but what if there are certain instances where I don't > need to know the products of an order? Should I still be returning order > information with products if I don't need it? What about updating > the orders > table or the order_products table where should the update methods exist. > > Would it make sense to create an OrderDAO which the updating, > inserting, and > reading of simple order records, an orderProducts DAO which handles the > update, inserting, and reading of orderProduct records, and a > CompleteOrderDAO which is a join of the two tables for returning complete > orders but not doing any updating or inserting? > > Thanks for your input. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Barney Boisvert > Sent: Thursday, September 15, 2005 1:41 PM > To: [email protected] > Subject: Re: [CFCDev] Table joins DAOs > > Don't think of entities in relation to your DB tables. The two often > line up, but that's coincidence. Think about your entities. Each > entity type should have an object that deals with persisting objects > of that type. If that means one table, then it's one table. If it > means five tables (which might be indicitive of a modelling problem), > then your DAO will hit five tables. > > Simply put, DAOs persist single entities, whatever it takes. > > cheers, > barneyb > > On 9/15/05, Joe Ferraro <[EMAIL PROTECTED]> wrote: > > > > > > > > When creating a dao / gateway / whatever you may call it (your > object that > > accesses the database) and you need perform a table join should > you create > a > > separate object which job is to query against the joined tables as the > > representation of one entity? > > -- > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com/ > > Got Gmail? I have 100 invites. > > > ---------------------------------------------------------- > 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]
