I've been in the same situation myself so can definately understand where
you're coming from but wouldn't you need to make these changes whether or
not you were usinng DAO's etc. If you change the underlying structure of the
table, then the your sql and validation logic will need to be updated
regardless of how you structure it. Definately interested in hearing
alternatives though.
Cheers, Pete (aka lad4bear)
----Original Message Follows----
From: Marlon Moyer <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: [CFCDev] Better way than dao, gateway, bean
Date: Thu, 18 Aug 2005 10:35:02 -0500
I've been using dao's, gateways, & beans for several months now.
Initially it seemed like a very good solution to separating out code
and it seemed like maintenance would be easier. Nowadays I'm not so
sure that this is the case. Recently I had a project where I was
creating a pdf form report. I had 4 revisions brought to me where
extra fields were requested. The work flow went something like this:
1. Add/change fields in database
2. Add/change fields in bean (getter/setters, initialization code,
validation code)
3. Add/change fields in gateway (selects)
4. Add/change fields in dao (select,insert, update)
5. Add/change fields in manager object that supplied the fields to the
fdf generator.
X 4
The amount of maintenance work hasn't diminished at all. It's
increased! Recently I've been playing around with a bean creator made
by Francis Scott. It queries the database for the table structure and
will automagically create the DAO, gateway, and an input form. It
works great, and you can easily use these as a base to create the rest
of your needed code. Obviously, you'll need to create more specific
functions in the gateway and input forms. What I was pondering was
how to make this automatic. How could I create a cfc that, given a
datasource and a table name, would automagically create a structure
for that table, dynamically create the crud methods and simple gateway
methods. You'd then extend this cfc to add additional functionality.
The downside I see to this is that you'll be relying on loops inside
queries to save all of the data. But the upside is that table changes
would be immediately recognized once you reinstatiate your cfc.
Also, I'm starting to lean more towards a TO vs a bean. Validation
inside the bean seems clunky. Form data comes as a struct. Why not
process it as a struct. A separate validation CFC seems to be a
better fit. Again, this could extend another base cfc that would
automatically understand basic database validations such as max length
of varchar, valid numeric values for numeric type fields, nullable
fields. Then on top of this, you could add your own business logic
type of validations.
Enough rambling for now. I think I'll try putting this together.
Marlon
--
Marlon
"A mulatto, an albino, a mosquito, my libido"
----------------------------------------------------------
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]
_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters!
http://www.msn.co.uk/newsletters
----------------------------------------------------------
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]
