a fair point, Blair the other side of the equation of course is too much hand-holding that it gets in the way, either by abstracting too much of the detail so you don't know what's happening under the covers - or - it just plain gets it wrong in edge-cases (special headers needed in CF webservices spring to mind)
I've still got a great memory of a WebDU breakfast a couple of years back where Chuck was showing how easy it was to build an ASP.NET application in VS2005 ... which promptly broke when he ran it and he had to go back to rebuild it and apply some setting he'd forgotten ... happens to the best of us. but this isn't helping Adam much... Adam, if you're still reading this, revisit the CFC dev website to get a feel for how important "it depends" means when someone like Sean Corfield says it. simple things will get you most of the way there - keep your view totally separate from your data access code - identify the "Gold" code (ie: it costs a fortune to make) and protect that "investment" (eg: from change + retesting) - you can probably get away with having DAO's for single record access (CRUD) and "gateway" CFC's for the rest. At least it's something. Lots of choices to join up the middle bits - look at what Transfer can give you as a way to get things happening quickly for data access - queries are more convenient (and faster) than arrays of objects, structs easier to pass around than single objects - you gotta know the rules before you break them but breaking them is OK --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
