> 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.
I was referring to excessive round tripping, not to the performance of the queries themselves. > 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. A ColdFusion query is a data structure, not an object. It's an important distinction. Nevertheless, I understand what you're saying. > 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. I agree, if the purpose is really is just to make the code look more OO. :) That's why the Gateway object (in the Mach II Development Guide), returns ColdFusion queries rather than transport or business objects. Anyway, I agree with the more general point. Using the intrinsic data types is generally more efficient -- and less safe -- than encapsulating data access in components. > The CF Query object is consumable from CF, Java, and .NET - those are our > target platforms. It works quite nicely. Ahh. I understand now. This is exactly why we need to use common terminology. A ColdFusion query is a data structure. It has several immutable properties which the caller cannot directly manipulate (like the recordCount and columnList). However, it's still not much more than a structure of arrays. > 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. That's probably because that's not the problem the DAO pattern is trying to solve. That's what gateways and other patterns attempt to address. In the Fowler book, for instance, he discusses Active Rows, Row Data Gateways, Table Data Gateways, Data Access Objects, Finders, and various other patterns for dealing with data at various degrees of granularity. Some return full fledged objects, others return record sets, and still others return instances of themselves. Anyway, the point I'm trying to make is that there's far more patterns out there than data access objects, business objects, and beans. In fact, most developers don't even use the term DAO in the same sense. :) Some of these patterns are more efficient at dealing with larger result sets. In fact, that's the whole reason some of them exist. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ---------------------------------------------------------- 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
