On 5/7/05, Dave Merrill <[EMAIL PROTECTED]
> wrote:
Sam, sounds right. Any chance of seeing your generic cfc, and maybe a usage
sample?
Write privately if you'd like.
Dave Merrill
> No tree barking going on at all. I've been using a method similar to this
> in development projects for over a year, with great results. All
> of my projects
> are growing, changing projects, and maintenance has been easy.
>
> I have a
> GenericData cfc that does introspection to detirmine field types
> and names.
>
> I then extend the cfc for each table, using cfproperty to make table and
> field properties available to the introspection of the base cfc.
>
> This method
> works great. I usually start with the inherited CRUD methods, and
> then override
> them in the extended cfc when additional complexity is needed. I
> don't spend
> time anymore writing trivial SQL. I only spend the time when
> something custom
> is needed.
>
> While there are certainly bad ways to accomplish the things
> we are discussing, the principle is right.
>
> -Sam Curren
>
>
>
> --- [email protected]
> wrote:
>
> > Dave Merrill wrote:
> >
> > On another level, my current
> thinking is that all DAOs inherit from a
> > base
> > DAO class, which contains
> generic parameterized versions of some common
> > methods. Instead of writing
> a delete method from scratch, for instance,
> > an
> > area's DAO can use
> this inherited method, passing it the arguments from,
> > pk_col_name,
> and pk_list. Similarly, a generic single-table save method
> > can
> > manage
> both inserts and updates, based on passed arguments. If things
> > are
> >
> unusual or more complex, the area's DAO can skip these generic
> tools and
>
> > use
> > its own ad hoc method.
> >
> > What do folks think about
> this?
> > Honestly, I don't think it's a great idea. DAOs are used to separate
> your
> > data persistance layers from your model. It appears that while building
> the
> > application, this method might save you some time - but maintainence
> would
> > be a pain. I have enought to remember what to pass in - yet alone
> column
> > lists etc... Plus, I'm using a factory pattern and abstract classes
> for my
> > gateways and daos. I like knowing I can call:
> > variables.appConstants.getGatewayFactory().getEamaGateway()
> and I have my
> > eamaGateway (I'm using Mach-II here...). Plus, I'm passing
> in objects
> > (beans or TOs)...ah, I think I would go nuts.
> >
> >
> > --
>
> > Peter J. Farrell :: Maestro Publishing I've been thinking about this for
> a
> > while, and I don't understand this response.
> >
> > - Why would maintenance
> be a pain?
> >
> > - How could you write a specific purpose-built insert method
> that didn't
> > include a column list?
> >
> > - Would you rather remember this:
>
> >
> > ==================
> > <cfquery name="qry_insert" datasource="#getDSN()#">
>
> > SET NOCOUNT ON
> > INSERT users
> > (last_name, first_name, email_adr)
> > VALUES
> > (
> > <cfqueryparam cfsqltype="CF_SQL_VARCHAR"
> value="#arguments.last_name#">,
>
> > <cfqueryparam cfsqltype="CF_SQL_VARCHAR"
> value="#arguments.first_name#">,
>
> > <cfqueryparam cfsqltype="CF_SQL_VARCHAR" value="#arguments.email_adr#">
>
> > )
> > SELECT @@IDENTITY as new_id
> > SET NOCOUNT OFF
> > </cfquery>
> > <cfreturn
> qry_insert.new_id>
> > ==================
> >
> > or this:
> >
> > ==================
>
> > new_id = DAO.create(
> > table="users",
> > last_name="#arguments.last_name#",
>
> > first_name="#arguments.first_name#",
> > email_adr="#arguments.email_adr#"
>
> > )
> > ==================
> >
> >
> > It's *not* about saving typing for the
> developer. It's about:
> >
> > - Having a replicable plan for similar methods,
> so you and other coders know
> > what to do, and what to expect as the return
> value, without thinking about
> > it. Like any framework, the idea is that
> once you've seen how the users area
> > handles inserts, you understand how
> every non-exceptional area does it.
> >
> > - Having a facade to the create
> method, so different generic
> > database-oriented DAOs with the same interface
> could be instantiated for
> > different back ends. The alternative is hand
> coding raw sql for every create
> > method, and rewriting it for every different
> back end.
> >
> > - Not diving into db implementation details every time you
> write an insert
> > routine. (Not that these are real obscure or anything.)
>
> >
> >
> > As far as passing in a TO, I don't see how that changes things.
> An area's
> > DAO would just pass values from the TO into the generic create
> method,
> > rather than passing column-specific arguments it received. If the
> TO
> > represents a single table, and the TO field names and sql column names
> were
> > the same, the second version above could even be written:
> >
> >
> new_id = DAO.create(table="employees", argumentcollection="#TO#")
> >
> >
> If the TO is a complex object, w data from multiple tables, the area DAO
> > would call DAO.create multiple times, passing each embedded sub-object,
> with
> > a different table name for each one. This is just like a non-generic
> version
> > would do multiple cfqueries.
> >
> >
> > Am I barking at the moon
> here?
> >
> > Dave Merrill
----------------------------------------------------------
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]
--
Aaron Rouse
http://www.happyhacker.com/ ----------------------------------------------------------
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]
