I almost agree with Jared here in general. However, I can't be as black and white about it.
For instance on a project I worked on before that had users (with addresses) and students (also with addresses). I had an address DAO - but it didn't do any read operations. Just update and create. The read and delete were in the user and student DAOs which involved joins to get the entire profile of the user or student. I couldn't use lazy address initialization on the reads since whenever the student or user is displayed as a single entity I had to also display their address information. Hence it made sense to have the join (and would have been foolish not to) and thus the reading of the address was part of the student / user DAOs. So while I don't try to set up my objects to map perfectly to my schema - I also don't like to duplicate code such as the creation and update of the address. However, in the ideal world the address creation and update stuff would have been in stored procedures (as would have been the creation of the user and student) at that point then I wouldn't have had an address DAO at all. This is why I initially said it depends on your circumstances. It is safe to map the two on a 1:1 basis - but it isn't always the best thing to do. On 7/15/05, Jared Rypka-Hauer - CMG, LLC <[EMAIL PROTECTED]> wrote: > I quit trying to force my DAO/GW classes to conform to a db schema. > > Your DAO should aid your model in accessing the data it needs... what if > you want to return one row of data from a set of joined tables? How do you > do that when you're restricted to one DAO/table? If you have a standard of > one DAO/Table, what do you do with a joined query? A special DAO? That > muddies your model. > > I've started taking the perspective that I use my controllers/listeners as > my oo-to-relational (ORM) mapping handlers and letting my DAOs fall in line > with the rest of the model, typically taking on one the form of DAO/entity. > Hence... a "user" entity that may be reflected in the OO model with 2 or 3 > composition classes (user, address, roles) will also have one DAO that > queries for rows from any relevant tables. > > Abiding by the one DAO/table rule sort of breaks the back of the whole > relational DB concept AND doesn't help your model or application's > efficiency in any way. > > HTH, > J > > On 7/14/05, John Samson <[EMAIL PROTECTED]> wrote: > > > > If a project is to follow a predetermined industry standard database > schema (PPDM Lite) then would there be scenarios where we wouldn't simply > define an object and a DAO for each database table? > > > > I can see that inserts into multiple tables can easily be done from a DAO > but it seems more straight-forward and safer to create an autonomous handler > (and object) for each table. > > > > Experiences? Observations? > > > > ________________________________ > Yahoo! Messenger NEW - crystal clear PC to PC calling worldwide with > voicemail > ---------------------------------------------------------- > > 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] > > > > > > > > -- > --------------- > ------------------------------------- > Buy SQLSurveyor! > http://www.web-relevant.com/sqlsurveyor > Never make your developers open Enterprise Manager again. > ---------------------------------------------------------- > > 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]
