Fair call about the MAY EVER...Some people are more imaginative about things that are likley to happen than others.
Myself, i dispute the reasoning about using daos cos one day you may change your DBMS. I have yet to see anyone ever say ...hmm i want an oracle db instead of a mySQL one for my shopping cart or CMS. Commercial products that get deployed all over the place are a different story..
I think its something you need to document and weigh up against your budget. Maybe even doing the excercise of giving it a 1-10 scale of how likely that area may change in the future could give you some perspective on what areas to make separate DAOs and what areas just to combine.
e.g
Address information - 9/10 - im almost certain an address will appear somewhere else
Order lines of an an invoice - 6/10 - theres a good chance a report will just want line items not the total order.
..
im actually at a loss to think of something thats unlikely to be broken apart, maybe thats the problem of why its such a complicated thing to determine!
anyways i think you get the idea...theres MAY EVER, but dont be too paranoid or optimistic about it.
Pat
On 9/16/05, Bill Rawlinson <[EMAIL PROTECTED]> wrote:
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]
----------------------------------------------------------
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]
