Sean, I was using configure() because of init() because I am using the mach II framework. Although the majority of my CFC objects won't extend the machII.framework.listener. So I could switch back to init() instead on objects not extending the framework. Although that seems like some overhead. I just rather stick with one initialization method name.
The thinking behind the Store_auction is that right now it grabs data from a MS SQL db, but in the future depending on configuration, it could grab from an xml file, some webservice or even an OO DB. Is there another way you would achieve this minimizing the footprint if any on your object layer? Should I simply return a query object to my auction object and do the assignment there? As for the getX setX, I implemented it this way, because I was under the impression that I should not access data or set data directly whether from another cfc or within a cfc. Am I mistaken? I understand that the true benefits of setter and getters would be if there was some kind of operation or task that needed to be executed to get a *real* value. Thanks for the feedback. Sean S. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield Sent: Thursday, September 11, 2003 3:51 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] DB and OO question I assume you're using 'configure()' rather than 'init()' because you're writing Mach II Listener objects? Otherwise I'd stick to 'init()' since that's more standard (and only use 'configure()' in Listeners. It seems like you're doing a lot of duplicated work: you convert your query into an object in the Store_Auction and then you copy all that data again into your Auction object. You're also falling into the getX()/setX() trap that I recently blogged... If you have a 1:1 relationship between your data members and your public getX()/setX() methods then you are not encapsulating anything. Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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 word '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]
