I'm new to the list
Welcome!
1.) I noticed that on Sean Corfields article "Software Design Patterns for
Flash Remoting" (
http://www.macromedia.com/devnet/mx/flashremoting/articles/ facades.html ),
the facade is setup to just invoke the other components via cfinvoke.
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).
skeptic in me assumes that this would be a pretty big performance penalty
in a busy environment, esp. when passing big sets of data between the
components since you are instantiating the CFC each time you call it?
Well, you can mitigate that by paging the record sets - the performance penalty would be more related to the serialization / deserialization of large data sets rather than the facade. macromedia.com uses the facade pattern heavily and load testing hasn't shown any problems with it. We're using Mach II now which is very CFC heavy and that's holding up well under load testing too (now that we've fixed the thread safety bugs - see release 1.0.8)!
The main reason I'm trying to keep each datasource seperate is so that a
developer can check out a single file for each datasource if it needs to
be modified rather than checking out a CFC which contains all of them
which more than one person might need to use at the same time.
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).
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 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]
