Hi guys,
I've been thinking about this for a few days now and although I can see why people would say 1 table = 1 Dao, I'm not sure it's always the case.
For Example, if you were building a Museum Guide application that had to support multiple languages, you'd expect to have a Museum table somewhere. However, in order to support an arbitrary number of languages, rather than one table, you'd end up with two. One table would contain all the language-neutral information and foriegn keys and the other would contain all the language-specific information. I've included a sample schema below:
Table Museum
MuseumId Integer (PK),MuseumName String,MuseumOpenTime Time,MuseumCloseTime Time,MuseumPhoneNumber String,MuseumTransport Integer (FK)
Table MuseumDetails
MuseumId Int (PK), (Matches MuseumId of Museum table)MuseumDetailsLanguageCode String (PK),MuseumDetailsSubject String,MuseumDetailsShortDescription String,MuseumDetailsLongDescription String
Note: This design allows us to add as many languages as we need but allows only one instance of each language.
As the data for a Museum is split across two tables, to Update one we'd need to update both the Museum table and the MuseumDetails table and do so inside a transaction so we could roll back if anything went wrong. (
i.e key violation caused by duplicate LanguageCode in the MuseumDetails table).
Now, if we follow the 1 table = 1 Dao mantra we'd have to handle our transaction outside of our Dao's and that's doesn't make sense to me. However, if we accept that our Museum is a single business entity, it makes senses to have a Dao that spans 2 seperate tables but represents it to the rest of the application as if it is 1 table.
I'm not sure if this is a great example but it's the one in my head right now and I'd love to hear other peoples views on the matter. It seems sensible, I guess the question is, is it? :)
Cheers,
Peter (aka lad4bear)
On 19/08/05, Munson, Jacob <[EMAIL PROTECTED]> wrote:
I remember someone asking on this list once, "Should I implement a DAO
for every table in my database?" Sure, and why not build the entire
DBMS from scratch while your at it. In fact, wouldn't it be really fun
to build a completely OO operating system from the ground up, making
sure to use ALL of the design patterns? And while we're at it, lets do
the same thing with the hardware!
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] ] On Behalf Of Joe Rinehart
> Sent: Friday, August 19, 2005 1:00 PM
> To: [email protected]
> Subject: Re: [CFCDev] Better way than dao, gateway, bean: <cfquery>
>
> > How much cfc's does it take to change a light bulb?
>
> Argh...I think is what people don't get about OO. If it's one kind of
> lightbuild, one class is fine.
>
> If you need to create a lightbulb changing robot that can handle many
> types of lightbulbs, things like the Abstract Factory Pattern would
> certainly add classes to your design, but would make the whole thing a
> lot easier to write.
>
> It's about motiviations / design forces, not implementing every
> pattern known to God (or Gamma) just for the fun of it. The "Oh my
> God, OO just adds sooo much unnecessary crap!" camp has probably
> simply had the misfortune of working with someone that uses OO
> unnecessarily.
>
> You may despise the DAO/DG combination because it's unnecessary for
> what you do, but when you're in a situation where you need to fulfill
> its consequence (separating data access from your application itself),
> it's a frigging godsend.
>
> -Joe
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. A1.
----------------------------------------------------------
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]
