lol ... yay for me :)
I like your view of transactions but am curious. In the past I've always made a distinction between business transactions and database transactions. The business transaction is "Did I complete TaskA and TaskB required to complete the process" and the database transaction is "Did the inserts, updates, deletes required for a each task work correctly". Now if TaskB is dependant on some operations in TaskA being committed I need a transaction somewhere. Are you suggesting it should be in my business object. Or maybe further back still and in my controller?
Sorry if I seem a bit befuddled but this is a bit of a head-shift for me and it's not quite clear yet.
Cheers,
Pete (aka lad4bear)
On 19/08/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
First, transactions are business logic, and if you've got business
logic in your persistance layer, you've got problems. Transactions
should be managed at the top of your business tier, because it's
business rules that define what makes up an "atomic" action on the
database.
Say we need to log business operations to a dedicated table in your
museum example. In order to get that logging to happen in the
transaction, you'd have to have your log stuff in EVERY DAO, which is
clearly wrong, since you're logging business operations, not
persistance operations. I.e. in your two-table update, we want to log
one "museum info updated" operation, not two per-table operations.
...rant over...
This is a perfect example of when the table/DAO ratio isn't 1:1. The
purpose of persistance objects is to abstract the actual persistance
mechanism from the application, so it's the ideal place to handle the
dual-table nature of the storage. The winning phrase: "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." Your application
just says "hey DAO, update this, would ya?", and the the DAO takes
care of putting the right data in the right tables, without your
application even knowing that there are two tables. Similar idea to
updatable views in some ways, though in-code rather than in-db.
So like everything else, the rule of thumb is one table per DAO. The
trick is to understand what's going on well enough to know when to
break the rules. And from the very concise example you provided,
you've got it. ;)
cheers,
barneyb
On 8/19/05, Peter Hardy < [EMAIL PROTECTED]> wrote:
> 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)
>
>
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 50 invites.
----------------------------------------------------------
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]
