On Thu, 27 Jan 2005 12:40:27 -0500, Roland Collins <[EMAIL PROTECTED]> wrote:
> I would wager that none of them will be able to match the performance of
> custom-tailored SQL queries.  They will the horribly inefficient code that
> winds up in most DAOs.

Not necessarily "horrible" but many of thse trade offs are acceptable.

> Right, but my goal is not to be a purist's vision of OO, so that's a moot
> point.  Besides, the query itself *is an object*, which also encapsulates
> data, albeit in a very loose manner.

Right, and that's an important point that I keep clubbing people over
the head with!

> I'm saying that passing around an
> object or a collection of objects that just wrap a query object just for the
> sake of looking more OO is a waste, when the query will suffice quite
> nicely.

And I'll agree.

> The CF Query object is consumable from CF, Java, and .NET - those are our
> target platforms.  It works quite nicely.

I didn't realize it was consumable from anything other than CF but
it's good to know.

> >If you _really_ want to get the best _performance_ you probably won't use
> >OO at all. :)

Yeah, Micha will tell us that OO is evil because of its inherent
overhead... But, to be honest, in large enterprise systems there are
many situations where an OO solution is actually the fastest
reasonable solution.

> When writing code for applications that don't manage _huge_ data sets, I
> quite happily write "pure" OO code.  I just don't find it (and in particular
> the DAO/BO pattern) efficient when dealing with large volumes of data.

Large volumes of data should be handled through data gateways which do
NOT convert everything to an array of objects or whatever...
-- 
Sean A Corfield -- http://www.corfield.org/
Team Fusebox -- http://www.fusebox.org/
Breeze Me! -- http://www.corfield.org/breezeme
Got Gmail? -- I have 5 invites to give away!

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' 
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at 
www.mail-archive.com/cfcdev@cfczone.org

Reply via email to