Inline comments :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Rogers Sent: Thursday, January 27, 2005 9:25 AM To: [email protected] Subject: RE: [CFCDev] Composition and SQL
>There are some relatively simple ways to solve that. Fowler addresses these >in his book Patterns of Enterprise Application Architecture. Keep in mind >that what many people refer to as a DAO, Fowler refers to as a Table Data >Gateway or Data Mapper (depending on how you're using it). He chose not to >use the DAO terminology because of confusion with the Microsoft technology >of the same name. Similarly, what people on this list call Gateways, he >terms Finders. 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. >That's fine, but it's not terribly object oriented. In object oriented >design, you try not to pass around raw data. Instead, you pass around >object references (a.k.a messages). The objects themselves encapsulate the >data. 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. 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. >> This has the benefit of allowing most of our functions to be >> exposed directly as webservices with no modification whatsoever, and >> without >> worrying about compatibility with our target platforms due to strange >> collections of objects. >Not sure I follow this. I don't believe you can return objects from a Web >service, just collections of data. The CF Query object is consumable from CF, Java, and .NET - those are our target platforms. It works quite nicely. >Encapsulating data access is not about database portability (though easier >database portability is often a benefit). That's where DAO factories and >such come in. It's about the single responsibility and DRY principles. Right, that wasn't my point - I was just pre-empting the argument that I knew was going to come my way :) >If you _really_ want to get the best _performance_ you probably won't use >OO at all. :) Agreed! ;) 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. ---------------------------------------------------------- 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/[email protected]
