I use SPs some depending on the project for instance the one I referenced in my previous post didn't use any SPs initially (at least not that interacted with the CF side) but as we are getting the chance we are moving to a more SP approach. The only time we won't be using SPs is for reading most likely. The delete, create, and updates will almost all be done in SP.
And while I can't really offer much more insight into the process i can give a warning. using CFSTOREDPROC you need to have your parameters in the right position - even if you provide the names. cfstoredproc (at least in cf5 and 6) does not work if you are just counting on using named parameters. If someone has actually been able to do this (pass in the cfprocparam in any order due to naming them appropriately) then I would love to hear how you got it to work. Thanks Bill On 7/15/05, Bagley, Brian <[EMAIL PROTECTED]> wrote: > 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] > > > -- [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]
