In CFSQLTool I tried several approaches to UDFs. The tool uses several UDFs for buildtime and for runtime code. I don't think there is any one fixed approach other than doing case study on the application to determine what is required for performance. In performance, I always look for the memory allocation cost and persistence requirements to keep malloc costs down. Request scope is more expensive than Session scope.

In the last release of CFSQLTool, for the runtime, it recommends using a top level CFC for the common UDFs in CRUD CFC across multiple tables. For example,
Rob Brooks-Bilson cflib.org's UDF isNull() is used in nearly every CFC for building the cfqueryparam null attribute on the fly. I recommend putting the isNull in the top level CFC.


I think one interesting benefit of doing the top level CFC becomes is not to set UDF.cfc in application scope but rather set the leaf object like a contacts object invoking a contacts_wrap.cfc that would get lots of hits in a CMS application. Since CFC extends means inherit functions, the contacts_wrap extending the UDF cfc loads with one time with one set of mallocs. Yes there may be some small memory expense for the extend functions, but by applying some application architecture design this can be reduced by having task related UDF.cfc. UDFs whose task are mainly for database can be in a separate CFC say, UDF_db.cfc, than ones whose task is mainly form checking, say UDF_form.cfc.

Joseph



-----------------------------------------------------------------------
http://www.switch-box.org/CFSQLTool/Download/

Switch_box                      MediaFirm, Inc.
www.Switch-box.org              Loveland, CO  USA

----------------------------------------------------------
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]

Reply via email to