I tend to agree, at least to a point.
In my first CFC-based app, I made the HUGE mistake of nesting
instances inside arrays inside of instances inside arrays... I think
at one point I had a user object that had an array of companies that
each had arrays of 3 different types of users that had companies in
them... I way trying to make my interactive objects (i.e.
session-scoped object resulting from login) as generic and complete as
possible at the point of creation.
The issue? Well, with a certain class of user it took 15 seconds to
log in and crashed the server randomly because his object contained
over 600 separate CFC namespaces, along with the overhead for arrays,
structures, and so on, that would simply hang Jrun. It was ugly.
So I backed up, simplified my model, and determined that if my old CF
code could run to the DB frequently, then simply moving to CFCs didn't
mean that I had to redo my ENTIRE coding paradigm... since I've been
using a pseudo-OO method I developed for myself (url-var controlled
consolidated action pages and a session.userInfo structure that
contained all relevant user data), I just revised my design and let
the CFC determine what it needed when and go get it from the DB. I
also incorporated stored procs because I was looking for a more tiered
approach along with a performance boost and the ability to alleviate
some of the demands on CF for DB logic... i.e. with 5 types of users,
the DB receives a username and password and simply returns a record or
not. No second trips to the DB for each usertype.
BUT, whenver I get data on a user, a company, etc., I'm abiding by Ben
Forta's use of the this scope in both the CFWACK and the Advanced book
by using the THIS scope to contain cf-accessible values. Something
I've struggled with, however, is this:
Why use this.username = query.username versus <cfquery
name="this.userdata">? Then, if I need to use struct notation, I can
simply do:
myUser = createObject("component","user.cfc").init(12) //12 = user_id
<cfoutput>#myUser.userData["fName"]#</cfoutput>
A query in this case would be faster, lighter, etc., but since an
object in memory is simply a struct-with-UDFs, and I USED to use a
session-scoped struct for concise storage of my userdata, why NOT move
the data from the DB into the THIS scope?
And, for that matter, do the proponents of the encapsulation
methodology propose a round-trip to the DB for each value, or do they
propose a collection of private instance data to be delivered to the
screen by a special method?
More randomness from MN,
Jared
On Sat, 25 Dec 2004 19:39:06 -0700, Joseph Flanigan
<[EMAIL PROTECTED]> wrote:
> What is the problem with using CFC this. variables? Are they not thread
> safe? Where does MM document they are not thread safe? Is there example
> code that would cause a thread failure using this. variables?
<snippage>
>
> Those of you who read this and who are encapsulation fans will not agree
> with me recommending the use of this. scope. So while I am on the topic,
> encapsulation means discrimination by design. It means declaring object
> definition and discarding all other possibilities. getter and setters is
> not encapsulation, it just one of many means to effect
> discrimination. Declaring a CFC defined with this scope instance variable
> is encapsulation by structure not by value.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net
http://www.cfhosting.net
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188788
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
