Hey Mike, All good questions, and Scott hit the nail on the head in his earlier reply - how you implement something like a CRUD DAO is something that varies according to personal taste. I'd recommend choosing a standard style among your dev team/group/etc.
> Can you explain why you went with this approach? It's the one I've seen most commonly used, and I think it's the easiest to learn. There are variations all over the place....for example, the Sun Core J2EE Patterns reference does the following: public int Insert(transferObject) //returns new key value, assuming numeric id public boolean Delete(transferObject) //true if success public boolean Update(transferObject) //true if success public transerObject Find(transferObject) //returns TO from a TO > 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()? It's easier to understand the Id version :). More often than not, DAOs I use would take a userTransportObject instead of a userBean or Id, much like Sun's reference example. My post was on the DAO concept though and aimed at CF developers who may not even know what a pattern is, and I didn't want to confuse anyone by suddenly jumping to DAO + DTO. > 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? For me, it provides a single place to implement things that need to happen to the object when it's persisted, like doing userBean.setDateLastUpdated(now()). The more I learn more about Design Patterns, the more I agree with Scott - "whatever blows your hair back." There's a lot of variation, but it's the concept of the solution the pattern provides that needs to remain consistent. Hope this helps - feel free to post more questions, and if anyone else has anything to add, please do so. Cheers, Joe For Tabs, Trees, and more, use the jComponents: http://clearsoftware.net/client/jComponents.cfm ---------------------------------------------------------- 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]
