Yep. My data all just appears on the pages - it's awesome ;)
I think that encapsulating every table (or object) in a database in its own
DAO adds a layer of overhead that is not often needed. Don't get me wrong,
I'm not saying it doesn't have its place, but many times, it's just not
necessary. Applying the DAO pattern to hide DB access by wrapping it in a
more object-oriented structure doesn't always reduce complexity - it can
increase it too.
For example, we use a lot of stored procedure for data persistence and
retrieval. So for user persistence and retrieval, for example, we would
have the following stored procedures ("IS" is our internal prefix for stored
procs):
IS_create_user (nm, logon, email, etc.) returns user_id
IS_get_user (user_id) returns query(nm, logon, email, etc.)
IS_update_user (user_id, nm, logon, email, etc.)
IS_delete_user (user_id)
IS_get_users_by_name (searchstring) returns query(nm, logon, email, etc.)
These SPs are called directly from our business layer using CFStoredProc -
our business layer always returns queries to the callers, so there's no need
to translate query-based results into any collection of objects, etc.
Now we _could_ move these SPs into a UserDAO, but there are several
arguments against it. For one, there's development time - why create an
object wrapper for these procs, when it's just as easy to call them
directly. Then there's overhead - moving these into a distinct object
simply means that we now have the overhead of creating and initializing an
object, when all it'll really do is call the SPs anyway. Finally, we don't
ever return DTOs or object-based representations of records. 99.999% of the
time, a recordset satisfies the output needs and translating things into an
object collection would really just kill an otherwise efficient system.
Hope that helps!
Roland
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Tim Van Der Hulst
Sent: Monday, November 15, 2004 3:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] table DAO
pixie dust?
hehe ;)
-----Original Message-----
From: Dawson, Michael [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 16 November 2004 9:32 a.m.
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] table DAO
How do you handle db interactions, Roland?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Roland Collins
Sent: Monday, November 15, 2004 2:28 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] table DAO
This whole discussion is why some of us think the DAO pattern is evil
(along with CRUD) ;)
----------------------------------------------------------
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]
