I just built a whole raft of DAO's using stored procs and it works well.
There were a couple of downsides though.
1) It's tedious. Writing the dao and setting up the method signatures and
<cfprocparam> list was very boring and I ended up switching between CF and
Enterprise Manager more times than I care to mention.
2) Changes to stored proc signature can get out of step with your CF code so
you have to be methodical when you do make changes.
When I was building the DAO's I kept thinking wouldn't it be nice if I could
1) autogenerate all these stored proc daos and 2) have a magic synchornise
button that would ensure my DAO's and database were in sync. So for my next
project that's what I'll be doing.
Anyway, just my experiences and I'm sure there are better ways to approach
it than the way I did it.
Cheers, Pete (aka lad4bear)
----Original Message Follows----
From: "Bagley, Brian" <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: <[email protected]>
Subject: RE: [CFCDev] One DAO for each dBase table?
Date: Fri, 15 Jul 2005 12:39:33 -0400
I have been watching this for a while now and I was wondering of there
is anyone out there using Stored Procedures for their database access
and how they are doing it in terms of DAO's and Gateways. It seems like
everyone is directly manipulating the queries in CF.
Thanks,
Brian Bagley
IT Engineer, Systems
216-447-7512
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Rawlinson
Sent: Friday, July 15, 2005 11:31 AM
To: [email protected]
Subject: Re: [CFCDev] One DAO for each dBase table?
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.
On 7/15/05, Jared Rypka-Hauer - CMG, LLC <[EMAIL PROTECTED]> wrote:
> I quit trying to force my DAO/GW classes to conform to a db schema.
>
> Your DAO should aid your model in accessing the data it needs... what
if
> you want to return one row of data from a set of joined tables? How do
you
> do that when you're restricted to one DAO/table? If you have a
standard of
> one DAO/Table, what do you do with a joined query? A special DAO? That
> muddies your model.
>
> I've started taking the perspective that I use my
controllers/listeners as
> my oo-to-relational (ORM) mapping handlers and letting my DAOs fall in
line
> with the rest of the model, typically taking on one the form of
DAO/entity.
> Hence... a "user" entity that may be reflected in the OO model with 2
or 3
> composition classes (user, address, roles) will also have one DAO that
> queries for rows from any relevant tables.
>
> Abiding by the one DAO/table rule sort of breaks the back of the
whole
> relational DB concept AND doesn't help your model or application's
> efficiency in any way.
>
> HTH,
> J
>
> On 7/14/05, John Samson <[EMAIL PROTECTED]> wrote:
> >
> > If a project is to follow a predetermined industry standard database
> schema (PPDM Lite) then would there be scenarios where we wouldn't
simply
> define an object and a DAO for each database table?
> >
> > I can see that inserts into multiple tables can easily be done from
a DAO
> but it seems more straight-forward and safer to create an autonomous
handler
> (and object) for each table.
> >
> > Experiences? Observations?
> >
> > ________________________________
> Yahoo! Messenger NEW - crystal clear PC to PC calling worldwide with
> voicemail
> ----------------------------------------------------------
> > 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]
> >
> >
>
>
>
> --
> ---------------
> -------------------------------------
> 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]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
----------------------------------------------------------
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]
Both the individual sending this e-mail and Noveon, Inc. intend that this
electronic message be used exclusively by the individual or entity to which
it is intended to be addressed. This message may contain information that
is privileged, confidential and thereby exempt and protected from
unauthorized disclosure under applicable law. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering the message to the intended recipient, be aware that any
disclosure, dissemination, distribution or copying of this communication, or
the use of its contents, is not authorized and is strictly prohibited. If
you have received this communication and are not the intended recipient,
please notify the sender immediately and permanently delete the original
message from your e-mail system.
http://www.noveon.com/disclaimer/cliquez_ici_pour_traduction_en_francais.htm
http://www.noveon.com/disclaimer/Fur_die_deutsche_Ubersetzung_bitte_hier_klicken.htm
http://www.noveon.com/disclaimer/Clicar_aqui_para_versao_em_Portugues.htm
http://www.noveon.com/disclaimer/De_un_clic_aqui_para_su_traduccion_al_espanol.htm
http://www.noveon.com/disclaimer/Chinese.htm
http://www.noveon.com/disclaimer/Japanese.htm
----------------------------------------------------------
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]
_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!
http://toolbar.msn.co.uk/
----------------------------------------------------------
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]
