Patrick, I agree with your post except for one point > if > you ever OR may ever, deal with those tables individually (say via 2 forms) > then you would be better off using 2 DAOs,
That "MAY EVER" part. Personally, I feel that you shouldn't go through the extra abstraction for MAY EVER. For instance if I have a person and an address but the address is only stored in the system in relationship to a person then I wouldn't build both a person and an address DAO. I'd probably wait till I actually needed it then refactor that part of the code. Of course, as with all of this stuff, you're milage may vary. If you are sure you're going to need to support addresses associated with more than just person in the future (ie defined in a requirement for later implmentation) then sure, you might create the second DAO now. Then I would use lazy loading of the address data for the person so that I'm not executing that second query unless I absolutely had to. This is a battle I struggled internally with for quite some time. And you have to determine what the best approach is for your project. For instance I have an issue tracker. An issue has an area, category, milestone. assignee, and a priority. Each of these have an interface in the system to create/edit. An issue also has a action history (things people have done on the issue). So for each there is a DAO that handles the CRUD methods. My issue DAO may return more than one record on the read method (due to the action history). When I call issue.read(issueID) I don't call each of these separate DAO's to get the data (I always need all of the details about the issue when I display it) so my issue DAO joins across the tables and pulls back the applicable data. Bill Cheers, Bill ---------------------------------------------------------- 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]
