>> Can't speak for Joe, but how you implement the CRUD routines is
entirely up to your space in life. If the Update() not only adds
information to the persist layer but contributes information to the bean
(ie dtPersistTimeStamp = Now()) then that can be considered a valid
reason for returning it back out provided your in the context of byRef
of the bean..(ie not shared amongst other objects aka byValue - probably
loosing it in translation here but lets say if you change stuff in the
bean/DTO it won't reflect unless being passed out). 

After I sent my email, the idea of adding a timestamp came to me.  I am
passing by reference, so is there any need of returning another (read:
same) instance from the method since I can just stick the timestamp
directly in the original instance? 

>> You could pass in an ID if the Read() routine is a simple db call
(which is your judgement call), and it will exist for the life of that
application. You could pass in a bean to act as a DTO in the end if
there is lots of arguments required to extract the data in question (ie
file location or multiple tables etc) - again your own judgement call.

As I said, whatever blows your hair back - I think its not meant to be
taken as gospel but merely a code illustration of the DAO concept being
applied.

Regards 
Scott Barnes. 
Pattern Code Monkey. 


> -----Original Message----- 
> From: Dawson, Michael [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, 22 December 2004 10:13 AM 
> To: [email protected] 
> Subject: [CFCDev] DAO Question for Joe Rinehart 
> 
> Joe, on your web site, you have an article named "Be a DAO 
> Disciple".  I have a question, or two, about your use of the 
> DAO object. 
> 
> You have four methods: 
> userBean Create (userBean) 
> userBean Read (id) 
> userBean Update (userBean) 
> void Delete (userBean) 
> 
> I noticed that the Read() method takes an ID number, while 
> the rest of the methods require a userBean object. 
> 
> QUESTIONS AS FOLLOWS: 
> Can you explain why you went with this approach? 
> 
> Why didn't you pass a userBean as an argument for all methods? 
> 
> Why didn't you pass a userBean only to Create() and Update() 
> while passing an ID number to Read() and Delete()? 
> 
> Why do you return a userBean object from the Update() method? 
>  Would that not be redundant since you already have the same 
> userBean that was used to pass to the Update() method?  I 
> don't see any reason to change the userBean in the Update() 
> method.  Are there any reasons to do so? 
> 
> Thanks 
> M!ke 
> ---------------------------------------------------------- 
> 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 
> www.mail-archive.com/[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 
www.mail-archive.com/[email protected]

Reply via email to