I tend to use create, read, update, delete, but I've seen it other ways.
That's just my humble opinion.
Joe Ferraro
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of John Farrar
Sent: Friday, September 16, 2005 8:05 AM
To: [email protected]
Subject: RE: [CFCDev] Table joins DAOs
NOTE: Thanks for changing the tenor of the conversation to details. When we
just use the terms and not the concepts, the posts were actually longer.
they seemed that way.)
Question: Is it common practice to create methods with detailed names like
"addCustomer" vs. "store" or something to that effect? It seems it would be
easier to use the later on because with the instantiated object name it
would be very obvious in the code what was happening. ( oCustomer.store() )
Also it would be obvious inside of your "customer.cfc" that the store
routine would be for the purpose of making a persistence of that data, in a
DAO going with the topic at hand, but wherever it was persisted. Just a
style question... or is there any common thought on such method names?
John Farrar
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Richard Rodseth
Sent: Friday, September 16, 2005 1:02 AM
To: [email protected]
Subject: Re: [CFCDev] Table joins DAOs
I just started reading Domain-Driven Design by Eric Evans. Excellent
book and Yahoo group. He uses the abstraction Repository for
persisting domain objects (actually only "entities" that are roots of
"aggregates"). My understanding is that the DAO (or other O-R mapping
is an implementation detail of the repository. So the client (eg. UI)
wouldn't be dealing with the DAO directly.
So CustomerRepository might have getCustomerByID(id),
addCustomer(Customer), saveCustomer(Customer) etc. But a Customer
domain object might be persisted in multiple tables, each of which
could have (but wouldn't have to have) a DAO and Gateway. I agree that
a DAO is for row-level operations (eg. update(CustomerData) and
aGateway for table-level multi-row queries.
- Richard
On 9/15/05, Patrick Branley <[EMAIL PROTECTED]> wrote:
OK,
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]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of
