> For performance reasons. I still use OOP as much as possible, but not the > DAO pattern in particular. OOP and DAO/BO in particular add a level of > abstraction that I don't really need (or necessarily want). There is an > inherent performance hit in the pattern for one, in that you're constantly > transforming data from the database to an object and then back again. > That's kind of a wasted trip if you don't absolutely need it.
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. > When we return data from a function, we return queries, almost > exclusively. > All of our pages expect queries, even when it's just a single element (in > that case, it's just a single row). That's similar to the way Gateways are defined in the Mach II development guide. > You still get all the benefits of the > dot-notation, with none of the transformation performance penalty. When > we > pass data into a function, we pass in each individual field instead of an > object. 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. > 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. > If we ever due have the need to enhance an > external > facing interface, we can always use Facades, without modifying any of our > internal API, and without adding the performance hit to our internal > business layer. > > In terms of database portability - we never have to worry about that. > We're > a hosted app, and I'm the one making the platform decisions. There's no > real reason for us to ever change. 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. > Not to mention, the truth is that if > you > ever _really_ want to get the best _performance_ (not necessarily the best > OOP API) out of an app, then sometimes breaking the OOP rules a bit is > going > to be necessary when dealing with the database layer, since most databases > are inherently non-OO systems. If you _really_ want to get the best _performance_ you probably won't use OO at all. :) > So the short answer is to keep it lean and mean! Our databases are > exceedingly large, so anything we can do to help the performance of the > interface helps a ton. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 > > > Hope that helps! > Roland > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Joe Rinehart > Sent: Wednesday, January 26, 2005 8:11 PM > To: [email protected] > Subject: Re: [CFCDev] Composition and SQL > > LOL. Sorry if I helped start any of that back on the ColdFusion Day of > the > DAO. > > I think DAO/BO is a friendly place to start thinking about things from > an OO perspective, as most CF apps are pretty closely tied to > databases. > > Out of curiousty, why do you avoid the DAO pattern? > > -joe > > > On Wed, 26 Jan 2005 19:41:39 -0500, Roland Collins <[EMAIL PROTECTED]> > wrote: > > I gotta ask - is there anyone else here that eschews the DAO pattern? > This > > list is more about the DAO/BO pattern than CFC development anymore! :S > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > > Of Mark Mandel > > Sent: Wednesday, January 26, 2005 7:16 PM > > To: [email protected] > > Subject: [CFCDev] Composition and SQL > > > > Hey guys - > > > > Just some thoughts going on in my head in concerns of composite > > objects and the SQL utilised in getting all their details. > > > > Reading Matt Woordards blog post: > > > http://www.mattwoodward.com/blog/index.cfm?mode=entry&entry=AF4AF196-5070- > 31 > > 18-2DBD6C4C381790A1 > > > > He talks about composition, and to copy paste: > > -- > > We're using composition in our beans, so why not use composition of > > sorts (this isn't strictly composition, but bear with me ...) in our > > DAO as well? When we instantiate the Person DAO, why not just > > instantiate an Address DAO inside the Person DAO so we can call things > > that way? > > -- > > > > Now, in my mind - there are two options for getting the PersonBO > > information and the AddressBO information. > > > > 1) Seperate SQL queries for both BO's - The Address DAO gets the > > results for a Address, and the PersonDAO gets the results for the > > Person BO - there are 2 query hits on the db. > > Pros: It's clean, and consise and really reusable > > Cons: For complex objects, that's alot of database hits - is that a good > > idea? > > > > 2) Joins between tables - a Gateway object (maybe?) gets a joined > > result by getting the relevent data form both the Person Table and the > > Address Table, and the DAO's intelligently create the BO's that they > > need from that single query's results > > Pros: It's alot more efficient than the above > > Cons: It doesn't exactly promote code reuses > > It also can get tircky as Joins can cause duplicate data to > > display, and you have to avoid creating the same BO twice or more. > > > > What is your thoughts on this, guys? It's always been something that > > make me think. > > > > Mark > > > > -- > > E: [EMAIL PROTECTED] > > W: www.compoundtheory.com > > ICQ: 3094740 > > ---------------------------------------------------------- > > 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] > > > > ---------------------------------------------------------- > > 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] > > > > > -- > For Tabs, Trees, and more, use the jComponents: > http://clearsoftware.net/client/jComponents.cfm > ---------------------------------------------------------- > 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] > > > > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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]
