so after all the ranting and questioning about the right terminology we can say that.
a dao deals with one row.
a gateway returns aggregate data.
you *could* implement it all in one object, but usually its done with two.
most of the time a dao deals with a business entity, that most of the time relates to one table, that most of the time deals with one form.
but *sometimes* you might have 2 tables. Wether you create one DAO or two really i my opinion depends on what else you use those other tables for. if you ever OR may ever, deal with those tables individually (say via 2 forms) then you would be better off using 2 DAOs, but if thats not likely to happen then u might as well just use one and save some typing.
your gateway could potentially return a business object of some sort like some kind of Iterator object OR you may bypass that and just return cf queries. I would say most of the time query is better...if its just for outputting the content to a page or some other format, then anything else is a bit of overkill. if you find that the query you are consuming from the gateway doesnt cut it..ie. it becomes complex to use the data you have gotten back, then look at building an object to return from the gateway thats alot nicer to consume.
eg. your order and products gateway returns a query of joined orders and products that you use to output some kind of report. You find that you need to calculate lots of sub-totals for differnt things on the report and theres lots of calculation going on when outputting the results. In this case its time to build a business object.
if you just need to dump the data out to a page, then just use a query. thats what its for! :)
my 2c
Pat
On 9/16/05, Bill Rawlinson <[EMAIL PROTECTED]> wrote:
> In fact
> it would be good to create a lexicon of terms on the site this list is from.
> Then we could reference people to definitions and examples and spend our
> time here discussing how to, and why we do.
>
Of course in order to do that you would need to have a discussion that
brought about a mutual undestanding of these terms so that they could
be properly defined and then posted on said lexicon.
That is why, I think, most folks on this list typically refer to
Fowler's definition on Patterns. Other terms, such as encapsulation
and inheiritance, have commonly accepted definitions in the computer
science community at large. As do coupling, cohesion, interface, etc.
People will often uses these terms incorrectly, either via ignorance
(I'm not trying to be mean, they just really don't know what the term
means), or accident. The former is easy to correct. Look up any
introductory computer science tome (boy, i don't get to use that word
often) and check out the glossary. The later, well that is what folks
like Ben are for. He noticed a miscommunication and fixed it. This
saves everyone confusion (especially those in the former group who
didn't know what a word meant and might have walked away with an
incorrect understanding).
I think this list is generally pretty helpful for people of all skill
levels. Some times terminology has to be hashed out in the
conversation. But that is good. It will help you both here and give
everyone involved more experience in communicating ideas (and asking
probing questions to find out what someone else was really talking
about - i'm sure we have all had customers where we have though,
"HUH?" after they tried to tell you what they wanted.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
