Re: Static variables in ASP .NET/VB .NET

by RB on 11/1/2007 9:16:00 AM Hi Peter,

The advantage is that it's an easy way of caching objects for the
duration of the page - think of it loosely like the singleton pattern.

I could do the same thing with private variables within the class of
course - I just think the static approach looks neater!

I was just a little concerned that it would not work the way I thought
it would - hence my posting...

Cheers,

RB.

Peter Bromberg [C# MVP] wrote:
> Perhaps, but I fail to see what advantage this could possibly give you.
> Understanding that the Page class disintegrates --*Poof* and is completely
> gone when it has finished and the page is sent out to the requesting browser.
> Static -- within the context you are using it (in private transient scope)
> accomplishes "nada".
> -- Peter
> Recursion: see Recursion
> site: http://www.eggheadcafe.com
> unBlog: http://petesbloggerama.blogspot.com
> BlogMetaFinder: http://www.blogmetafinder.com
>
>
>
> "RB" wrote:
>
>> AHHH - I think i know what's going on - I'm being a thicky (naturally!)
>>
>> Every user has their own instantiation of the page object in question,
>> so the procedure level static variables *are* individual to each user,
>> as the procedure they are in is not shared.
>>
>> Therefore, it is safe to use this technique (of caching things in a
>> static variable) as different users will not be able to share values.
>>
>> If the above is not correct, please let me know!!
>>
>> Cheers,
>>
>> RB.
>>
>> RB wrote:
>>> That's what I thought as well - but doing testing suggests that
>>> procedure-level statics work differently, and exist only for the
>>> lifetime of the page.
>>>
>>> Ah - is that the thing then. Is it the case that if I had 2
>>> near-simultaneous web-page requests, then the static property value
>>> *would* be shared?
>>>
>>> bruce barker wrote:
>>>> statics are statics, shared for all threads in the appdomain. public
>>>> and private only controls scope (access).
>>>>
>>>>
>>>> -- bruce (sqlwork.com)
>>>>
>>>> RB wrote:
>>>>> Hi clever people :-)
>>>>>
>>>>> I've noticed a lot of people stating not to use static variables with
>>>>> ASP.NET, and, as I understand it, the reason is because the variable
>>>>> is shared across user sessions - which is Very Bad (tm) for reasons I
>>>>> understand!
>>>>>
>>>>> However, does this rule apply only to global static variables, or
>>>>> does it apply to procedure-level static variables.
>>>>>
>>>>> e.g. If I have a class:
>>>>> ==================================================
>>>>> Public Class MyPretendClass
>>>>> Inherits System.Web.UI.Page
>>>>> ReadOnly Property SomeProperty() As Integer
>>>>> Get
>>>>> Static i As Integer = -1
>>>>> If i = -1 Then
>>>>> i = Integer.Parse(Request.Params("MyQueryStringArgument"))
>>>>> End If
>>>>> Return t
>>>>> End Get
>>>>> End Property
>>>>>
>>>>> ' REST OF CLASS, INCLUDING USE OF SomeProperty PROPERTY
>>>>> End Class
>>>>> ==================================================
>>>>>
>>>>> and I output SomeProperty to an asp:Label how will it work if I have
>>>>> 2 users (Alice and Bob), where Alice requests the page with a query
>>>>> string value of 1, and Bob then accesses the page with a value of 2.
>>>>>
>>>>> Obviously Alice will have 1 in the label, but what value will Bob have?
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> RB.
 

Re: Static variables in ASP .NET/VB .NET

by Mark Rae [MVP] on 11/1/2007 9:36:00 AM "RB" <owmdkbqzikigpu@mailinator.com> wrote in message
news:0K6dnaBPLL5-BLTanZ2dnUVZ8qeknZ2d@eclipse.net.uk...

> The advantage is that it's an easy way of caching objects for the duration
> of the page - think of it loosely like the singleton pattern.

I guess it depends on your definition of the word 'advantage' - in this
case, there's no advantage (IMO) at all, since you get no additional benefit
or functionality...

> I could do the same thing with private variables within the class of
> course

Indeed, which (I believe) was Peter's point...

> I just think the static approach looks neater!

Well obviously that's a personal preference, and nothing wrong with that...


--
Mark Rae
ASP.NET MVP
http://www.markrae.net