Doug, would it be so simple as to have: getRecords() -- returns all records getRecords(id) -- returns selected record
Or is it better to separate, yet duplicate some code, such as: getRecords() -- returns all records getRecordByID() -- returns selected record -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug James Sent: Monday, November 15, 2004 1:19 PM 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 ---------------------------------------------------------- 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]
