> 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.
IMHO, I don't see the need to instantiate a bean just to pass in an ID number to a DAO for a Read() or Delete() operation. I think that is overhead that is not needed. However, a bean would be just fine for the Update() and Create() methods. > It's the one I've seen most commonly used, and I think it's the easiest to learn. Agreed. It finally "clicked" yesterday after a few weeks of playing around with a few patterns. Whee! > 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. I looked at a TO definition, but couldn't really make out the differences of a TO and a bean. > 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()). This makes perfect sense to me 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. Yes. Now that you, and Scott, have cleared up my question of "the right way", I can feel comfortable with doing it "my way". I have to start somewhere and I'm sure I'll find I didn't do it correct (or what feels good) the first time, but I have seen that a somewhat-OOP approach will make it much easier to refactor the code. In fact, I built a small application using only procedural code, with inline function definitions. Once I got the application to work the way I wanted, I then had a blueprint of how my objects should work. Being new to OOP, it was too confusing to "start fresh" with objects before I knew how the application should finally work. > Hope this helps - feel free to post more questions, and if anyone else has anything to add, please do so. Thanks, Joe. This was a valuable resource for me. 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]
