Our DAOs are like gateways just different terminology. Our DAOs generally look like this.
Create returns numeric (id) Read returns recordset with one row or struct if data is not flat Update returns void Delete returns void // then have gateway methods for getting multiple rows of data getFoos returns recordset searchFoos returns recordset We use machii and the tartan framework and this implementation works very well for us. What does everyone think? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Thursday, September 15, 2005 2: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]
