No you'd have a method in your DAO (to use my way of doing things) becuase
it's teh DAO that contains all teh database accesses. IF there are lots of
different ones, you might want another kind of component but for all my cfcs
a single DAO is enough.
In your UsersDAO you might have a method like this:
<cffunction name="getEmails" access="public" output="false"
returntype="query" hint="Returns a query of email addresses.">
<cfargument name="matchstring" required="yes" type="string" />
<cfset var qEmails = 0 />
<cfquery name="qEmails" datasource="#variables.dsn#">
SELECT emails FROM users
WHERE email like '%#arguments.matchstring#%'
</cfquery>
<cfif qEmails.recordcount GT 0>
<cfreturn qEmails />
</cfif>
</cffunction>
Ok, so far all thats different from the way you'd normally do it is you have
some extra typing, some extra lines of code, a new file (the cfc) to look
after. But now have a look at how you would use this in the page where
you wanted to process that query:
In that page, you'd typically have the DAO component (containing all your
database operations in the one file) already initialised at the top of the
page - with something like:
<cfset usersDAO =
createObject("component","#request.appmapping#.cfcs.UsersDAO").init(
request.dsn) /> which creates the DAO object and tells it which datasource
to use.
Ok, so far all we've seen is additoinal work. But now, look at this ...
down the page you can have this:
<cfset AolEmails = UsersDAO.getEmails("AOL") />
That runs the query through teh DAO component, passing it the value "AOL" to
filter by. Oh hang on. what about this then?:
<cfset BigpondEmails = UsersDAO.getEmails("Bigpond") />
<cfset iinetEmails = UsersDAO.getEmails("Iinet") />
Now there are three queries you can manipulate on your page. not to
mention (if you also had your methods set up in the cfc:
<cfset Foxaddresses = UsersDAO.getStreets("Fox") />
OR if you have the isp as a variable .. now you can have
<cfset isp = form.isp />
<cfset ispEMails = UsersDAO.getEmails(form.isp) />
Now with the one single query , in the one file (the DAO cfc) you can
filter, search, list a variety of ways, without needing to change your
query.
Now what if you change your database? Where are all your queries? If
your code is like most of the ones I inherit in my contracting work, you'll
have queries all over the place in dozens of files. using this OOP
approach, you'll know before you start working that a change to teh Users
table will require work on teh UsersDAO.cfc file and quite probably that's
it.
I've glossed over quite a few of the details, in order to try to illustrate
where this starts to pay off, but i hope it helps.
Cheers
Mike Kear
Windsor, NSW, Australia
Certified Advanced ColdFusion Developer
AFP Webworks
http://afpwebworks.com
ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month
On 3/7/06, Rick Faircloth <[EMAIL PROTECTED]> wrote:
>
> > I hope this description is helpful without being over complicated. :)
>
> No, that actually was fairly understandable to me.
>
> I wasn't relating a "bean" to a query representing a single
> row in a table, but to a query that might return all users, etc.
>
> If I needed 5 different queries...saying one for email addresses
> containing "aol" and one for street addresses containing "Fox",
> etc....what would I do?...create a "bean" for each one of those
> queries and store them in memory?
>
> (Where's my picture? ;o)
>
> Rick
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234369
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
