When I built CFCSQLTool, I spent quite a bit of time testing and trying alternative ways of handling data access layer (DAL) instance data variables for table wrapper CRUD. The solution I chose was to instance DAL data with the CFC using the this-scope variables.
Here is the reasoning.
At runtime, the CFC acts as a complex data structure where keys for functions and instance variables have namespaces as variable names. Instance variables are of type either this-scope or variables-scope. A main difference between the two types is the means of setting values. From the application perspective, this-scope values can be set as object names whereas variables-scope require functions for setting and getting values. (Programmers who practice encapsulation use the terms getters and setters to refer to variable-scope functions.) Another difference, is that with this-scope namespace memory allocation occurs once whereas with function calls require several memory allocations. But, because the DAL does so much work, reducing memory allocations seems the better programming option.
The build-time approach I like for coding is to split a table wrapper cfc into 2 parts. One part for the CRUD functions and one part for the instance variable structure which extends the wrapper. For an example, see http://www.switch-box.org/CFSQLTool/doc_1_6_ReleaseNotes.html under topic example service component.
Joseph
At 07:01 PM 10/3/2004, you wrote:
firstly let me preface this post with two cavats:
1) I'm just looking for opinions, thoughts, etc to sway the decision one way or another. "Should we or shouldn't we" stuff
2) IMHO, the power (ands flexability) of CFC's comes from not just calling methods but in it's ability to store context data/values as well - "objects"
For our enterprise app at the moment (a web version of a 15 yo legacy app), all data is returned based on what company_id a user has logged in at. this means that every db table, every method call - everything - needs this company_id to work (ie: each db table stores multiple company data where the companies are subsets of a particular organisation).
(pls note: this is a legacy app - while I would not do things this way if I had a clean slate, it *does work*...)
this means that for app-wide values (not specific entity data) either:
- it may be pointless to store db data as object properties (depends on the user's context - session.company_id - from the login process) so the server-stored CFC's turn into no more than collections of UDF OR...
- store cfc properties as arrays, based on company_id. sure this is more work, but at least we can persist "objects" in server scope and cut down on the db hits
I know this is a wierd set-up but if anyone has any thoughts, opinions, advice, etc I'm all ears.
thanx barry.b
-- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
---------------------------------------------------------- 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]
----------------------------------------------------------------------- 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]
