> I have a rather simple project with only a handful of tables and so I used a single DAO.
So you handcode your SQL for each DAO? man... this topic diverged a bit. My original post was about a generic DAO object that eliminated the need to write SQL rather than stuffing it in the DAO which btw is the standard way of doing DAO's eh but no thats cool, hehe sorry to rant just waking up time for coffee ;) TiM -----Original Message----- From: Doug James [mailto:[EMAIL PROTECTED] Sent: Tuesday, 16 November 2004 8:19 a.m. To: [EMAIL PROTECTED] Subject: Re: [CFCDev] table DAO I think the structure of the DAO depends on the complexity of the project. I have a rather simple project with only a handful of tables and so I used a single DAO. I have a more complex application that has a base DAO that is extended by other classes to handle a specific type. I was on a project many moons ago where the architect called for a DAO per table, all interaction with that table had to go through its corresponding DAO. We could do no joins because we could not join DAO's. The design made simple processes extremely complex and, in my opinion, contributed to the failure of the project. Personally, I don't think I would limit my DAOs to single instances only. I would probably have a method to return a single instance and a method to return a result set. Just my $0.02. Doug James IT Developer MUSC - Hollings Cancer Center http://hcc.musc.edu Raymond Camden wrote: >>Also, DAOs usually provide data access for a single instance >>of an object, with the read method returning a transfer >>object instead of a multi-row query / array of transfer >>objects. If you need to select multiple rows (like your >>select() method), that'd traditionally fall into a "Data >>Gateway" object. A gateway would typically have methods that >>selected all records or records based on a given condition. >>(I think there's some debate over what a gateway should >>return though - I've seen both recordsets and arrays of >>transfer objects). >> >> >> > >I was wondering if you, or anyone, could comment more about this concept. >One of the problems I have with it is that I like the fact the DAO contains >all the SQL, but now we have 2 CFCs with SQL in them. Wouldn't it be nice if >all the SQL code for a particular bean was contained within one file? Why >should the DAO only work with one record? > >-ray > > >---------------------------------------------------------- >You are subscribed to cfcdev. To unsubscribe, send an email >to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' >in the message of the email. > >CFCDev is run by CFCZone (www.cfczone.org) and supported >by Mindtool, Corporation (www.mindtool.com). > >An archive of the CFCDev list is available at >[EMAIL PROTECTED] > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED] ## ## ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
