Roland, typically that is how I have approached all of my objects. However, I figure since I am rearchitecting an application (which is kinda clunky currently) I could experiment and learn more about different methodoligies (including DAO/Beans/etc).
Who knows what I will actually end up with I'm done - it is just an internal app and not one that needs to be finished in any hurry - another reason why I picked it to learn with (it is both complex and requires rewriting). Bill On Wed, 26 Jan 2005 20:27:39 -0500, Roland Collins <[EMAIL PROTECTED]> wrote: > Sorry for the double post (early ctrl-s on the last one). > > 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. > > 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). 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. 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. 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. 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. > > 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. > > 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: cfcdev@cfczone.org > > 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: cfcdev@cfczone.org > > 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/cfcdev@cfczone.org > > > > ---------------------------------------------------------- > > 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 > > > > -- > 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/cfcdev@cfczone.org > > ---------------------------------------------------------- > 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 > -- [EMAIL PROTECTED] http://blog.rawlinson.us I have 9 gmail invites,want one? ---------------------------------------------------------- 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
