Curious though, how do you actually use the DAOs? I have been treating them as static classes and have the CRUD functions accept an instance of the object...
<html><div>--------------------------------------------- <BR>Steven Boynes <BR>580 37th Avenue<BR>San Francisco, CA 94121<BR>(530)574-2129 (Home/Mobile) <BR></div></html>
>From: Joe Rinehart <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [CFCDev] table DAO
>Date: Sun, 14 Nov 2004 18:41:37 -0500
>
>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]
----------------------------------------------------------
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]
