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. (Or 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 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]
