Jerry,
Rather than creating UDF libraries you might consider using the Flyweight pattern instead. Flyweights are objects (usually Singletons) that have no internal state: they require all state or context information to be supplied with a method call (usually in the format of a Context object, but can be a struct or method args as well).
Basically you would create the Flyweights in the Application or Session scope, and then whenever you need their functionality you would just invoke a method and supply it with the context info it needs to run. You'd take a performance hit when the app first starts up and every flyweight object is created, but you could even mitigate that by using lazy initialization.
This approach lets you keep your code structured as objects instead of UDF libraries but also avoids the instantiation hit of all those per-request objects. The downside is that you have to juggle the context information externally as either a struct or another object, and the added complexity (or instantiation penalty for creating the context object) might negate the benefits of using flyweights.
On 1/21/06, Jerry Ela <[EMAIL PROTECTED]> wrote:
----------------------------------------------------------A timely question. I have a cfc based app and am being killed by the time it takes to instantiate the cfcs. I've moved anything I could to application or session scope, but have a lot of cfcs that need to be instantiated on a per request basis. I beginning to think I should change my cfcs into function libraries that modify external data structures instead of objects that manage instance data so I don't have to take the instantiation penalty.
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
