Hey Tim, Yep, some of us use the DAO pattern - I think you'll find it most used in the mach-ii crowd.
I think most of us are using a "dumber" (in awareness) DAO than what you describe. I think most people use a traditional CRUD DAO having four methods (and an "init" constructor): * public init(datasource) * public create (creates a new record) * public read (reads a record) * public update (updates a record) * public delete (deletes a record). Sometimes you'll see (and I often write) a "ScRuD" DAO that privatizes create() and update() and uses a public store() or save() method that calls insert or update as appropriate. >eg record(s) returned as objects not datasets 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. 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). There's a concept in the OO world called "cohesion" that I was reminded of this weekend when Sean Corfield uttered the cohesion mantra: "do one thing and do it well." A DAO handles single row-access, and does it really well. Adding methods to handle multiple rows makes the DAO a little more confused as to "who" it is. However, splitting into DAO and DG can help the indentity crisis - DAO operates on the data for one instance of an object, where DG operates on the data for multiple instances. >affected PID's and query names are stored in a server scoped struct 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? >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. > so yeah, just wondering how much u guys are having > to roll your own sort of solutions to some of this stuff or what? 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. It's cool to see more and more people interesting in doing more OO ColdFusion! Keep the ideas coming! -- 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 [EMAIL PROTECTED]
