>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.
I do this in generic cfcs: <cfargument name="objargs" required="no" default="#arguments#"> This way, you can pass in all the (named) arguments seperately, and objargs will populate itself, or you can pass in an object/form/struct, and it will still work. What do you think, elegant solution or nasty hack? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Collins Sent: 27 January 2005 01:28 To: cfcdev@cfczone.org Subject: RE: [CFCDev] Composition and SQL 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 ---------------------------------------------------------- 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
