Hi Joe thanks for the detailed reply :) > Yep, some of us use the DAO pattern - I think you'll find it most used in the mach-ii crowd.
Haven't explored machII yet, been holding out a bit and sticking with FB4, hehe. > There are some reasons you may want to look into using a transfer object instead of returning a ColdFusion query. The DAO serves to abstract interation with and the implementation of the persistence layer. Returning a query, to a degree, breaks this abstraction by assuming the data is persisted in a mechanism that "likes" queries. If you re-implemented your application with some of the components using LDAP or a Web Service as a persistence mechanism, you'd have to do some fairly low-level tinkering inside of their DAOs to return a ColdFusion query. Using an "implementation neutral" transfer object, such as a bean-style CFC or even just a structure can keep your DAOs doing 100% of what they're supposed to do - abstracting persistence mechanisms. yep i'd really like to create more service oriented data and business models. Working with cfquery is nice and easy tho, hehe ;) > Also, DAOs usually provide data access for a single instance of an object, with the read method returning a transfer object instead of a multi-row query / array of transfer objects. If you need to select multiple rows (like your select() method), that'd traditionally fall into a "Data Gateway" object. A gateway would typically have methods that selected all records or records based on a given condition. (I think there's some debate over what a gateway should return though - I've seen both recordsets and arrays of transfer objects). I'm not familier with Data Gateways, i'll have to investigate this :) > Is your DAO aware of the server struct (i.e., talks to it directly in its > methods), or do the objects created out of your result go into a > server-scoped pool of some sort through controllers? yes the DAO is aware of the server struct and no the objects (cfqueries,structs,etc) are not persisted if thats what you mean. You'll probably remark that accessing the server scope is a no-no huh, hehe. Also i've implemented a frequency based caching mechanism to persist the most frequently accessed queries (eg cfquery->cachedwithin) but don't have the need to use it much as our production server isn't exactly under heavy load, hehe I thought it was cool at the time tho, hehe ;) >>a session object to store a form struct in case a form fails to update > I've done this, you're right, it can be pretty handy! A lot (well, all) of my company's products were written for CF5 and earlier, and when some of us started backing multi-page/step forms with session-scoped CFCs, it helped the MX/more OO mindset start to catch on. hehe cool :) > I've rolled my own when building into existing apps, but if you're doing stuff from scratch, you may want to look into a framework like mach-ii (http://www.mach-ii.com/) or FuseBox. mach-ii is especially object oriented, and you'll find heavy use of patterns like the DAO pattern therein. Actually I dont mind not using a framework, Benoit Hediard's article on MVCF methodology has steered me well for extending/re-engineering a couple of my earlier non fusebox (ala cfmx spaghetii) apps, and some stuff in fusebox i don't seem to use or like all that much anyway, eg content variables (more flexible to use cfsavecontent), conditional logic in circuits, etc. cheers, TiM ## ## ---------------------------------------------------------- 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 [EMAIL PROTECTED]
