> > Well, not quite. The facade is stateless and, as you surmise, is > instantiated for each Flash Remoting call. It is fairly lightweight so the > overhead is minimal. The facade then interacts with CFC instances that are > stored in session scope, server scope and/or application scope as > necessary (as well as instantiating other, per-request CFCs).
That makes sense-- I think the missing piece for me was if the CFC's the facade was invoking would actually be stored in a persistent scope or not. > > I'd question your use of inheritance in this model - you're using it to > "reuse" implementation code rather than modeling an "is-a" relationship > really. You could just as easily use composition and embed a reference to > the database service object within the DAO (per-data source CFC). > I probably didn't quite go into enough detail of the design I have thus far, but essentially the various per datasource methods are mostly to check the validity of arguments. It uses those arguments to pass arguments to a separate DAO object which actually runs the query, handles paging, the size of the returned recordset, and so forth. I do think everyone's comments in combination with reading some more OO theory last night have helped me find something that is going to work though-- thanks! Also, thanks for adding the link Rob. I went back to the site this morning and had my foot in my mouth for a second since the link appeared out of nowhere for the archives, and I didn't remember seeing it before. :) I subscribed in digest mode, so I hadn't yet seen the link in the e-mail footers. Time to go check out the archives for a bit... - Brandon ---------------------------------------------------------- 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]
