Thanks Jared for the example and everyone else for their comments and observations.
A database model is the same as the kind of modelling that most people on this list are striving for. It represents real world objects and their real world relationships instead of our usual contrived understandings of them. I would suggest that the two (database and application / CF models) should therefore be identical in what they identify as 'objects'. This will lead us to a very simple one table to one DAO for Insert, Update and Delete actions.
There are often times when retrieving data that a join is required between two tables or it is simply inefficient to create an array of objects when all you want is a single attribute of each. Here I tend to lean towards Nando's comments in the Gateway CFC thread which is currently running and see this as another justification for having a separate Gateway component as well as a distinct dedicated DAO for single object persistance.
"Jared Rypka-Hauer - CMG, LLC" <[EMAIL PROTECTED]> wrote:
"Jared Rypka-Hauer - CMG, LLC" <[EMAIL PROTECTED]> wrote:
Hey Bill...
I didn't mean to be really black-and white... my point was just to not assume your 1:1 relationship between objects and tables.
When I wrote the CommonInterest app for the CFUnited website, I had one DAO in particular that got very interesting... due to a long-and-involved complication from having replication between 2 instances of the DB, I ended up splitting the passwords out of the main table and into a separate table... that consisted of 2 columns: userID and Password. When I had to update the user, I had no guarantee that they'd been updated before and couldn't therefore guarantee that a password was in the second table to be updated...
I ended up with 3 queries in that DAO's update method... an update query for the data I KNEW would be there, a delete query to get rid of a password just in case there was already one in the second table, and an insert query to put the new password in the passwords table.
Fortunately, it's one of the lesser-used pages of the site, is typically a smaller site anyway, and it was a temporary fix to deal with non-ideal circumstances... but the idea I wanted to get across is that your CRUD methods in your DAOs do what they need to do to support the model and that your application designs can be fluid. It's all about trade-offs and the needs of the app, system, clients, and situation.
That's all! :)
Laterz,
J
On 7/15/05, Bill Rawlinson <[EMAIL PROTECTED]> wrote: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.
--
---------------
-------------------------------------
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]
How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos. Get Yahoo! Photos ----------------------------------------------------------
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]
