I'm a newbie when it comes to CFCs in FB 4.1 but I'll try to answer this as
best I can.

>and this should accomplish the same thing. I also read BF's article on
>using CFC's where he says to initialize the CFC only once and then test
>to see if it was initalized on subsequent method calls.  What I'm
>confused about is if I have to initialize the CFC for each user or only
>once for the 50 concurrent members I may have on my site at one time.
>That is, can I just use instantiate or cfobject in my fusebox.init file,
>create it once, and then do method calls to grab data for any user
>currently on the site or do I have to instantiate a member object for
>each user separately?

The way you seem to have written the above question it seems like you are
just using objects to encapsulate database calls rather than taking them
for the full benefit.  An instantiated object is just that.  Think of it as
a physical object.  You don't build a car and depending on who is looking
at it the car is a Corvette or a Yugo.  You would create two cars (two
objects), a Corvette and Yugo.  And those objects exists until they are
destroyed.  Similarly with the members, Jill is not Mike and Mike is not
Jill.  When Mike was born (instantiated) he had characteristics like gender
and a name and without getting into talk about a sexChange method call,
Mike will never be Jill.  Given that, if you have 50 concurrent members
then there will be 50 objects floating around CF's memory.  Now, the
question becomes whether or not you 'instantiate' each member with each
request or do it once during a session.

I would highly suggest you look at Brian Kotek's sample application for the
bookstore in MVC FB4.1 and follow the pattern there with a Manager Object,
a Business Object, a DAO Object and Gateway Object. In that case, you would
instantiate once the stateless Manager Object (which has stateless DAO and
Gateway Objects) in the fusebox.init.cfm file with the if-lock-if as stated
above.  Then what you do is

<invoke object="memberManager" methodCall="getMember(url.memberid)"
returnvariable="myMember">

myMember would actually be a member object and you would get retrieve data
in your code like such:
myMember.getName()
myMember.getAge()
myMember.getPermission()
etc.

>I'm trying to avoid using the session scope.  Right now each user has a
>two cookies with their id and login status which I use to mimic a
>session state. Would there be any difference in the way I should handle
>this if I was using the session scope?

If the member logs in I see no reason to create the member object in the
session scope.  In other words
<invoke object="memberManager" methodCall="getMember(url.memberid)"
returnvariable="session.myMember">

That way you only have to pull the member's information from the database
once.  (I am making an assumption that your members are in a database
somewhere).

Jason Cronk
[EMAIL PROTECTED]



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support 
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49

Message: http://www.houseoffusion.com/lists.cfm/link=i:12:6726
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/12
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:12
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.12
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Reply via email to