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]
