Reputation: 10971
If I've got this class defined as part of an app in ASP.NET 2.0:
public class Foo
{
private static int _seed = 100;
private static object myLock = new object();
public Foo()
{
lock (myLock)
{
this.MyInt = _seed;
_seed++;
}
}
public int MyInt {get; set;}
}
(Edit: updated to account for thread safety concerns as pointed out by answers)
How will that static member behave? Will it start at 100 and increment separately for every session, or will it increment separately for every page refresh, or is it global...?
Note: I'm asking this because I'm using classes to model data for the first time in my ASP.NET app, and I've already discovered that C#'s by-reference nature appears to be ignored by ViewState serialization, so I want to know what other weirdness I can expect. For example, if I have this class defined (assume Bar
is another class):
public class OtherFoo
{
public List<Bar> Bars {get; set;}
}
and I do this on my page:
OtherFoo _myFoo = new OtherFoo();
//Code here to instantiate the list member and add some instances of Bar
Bar b = _myFoo.Bars[0];
ViewState["myFoo"] = _myFoo; //Assume both are [Serializable]
ViewState["myBar"] = b;
When I get those out of ViewState on the next postback, b
and _myFoo.Bars[0]
are no longer the same object.
Upvotes: 2
Views: 634
Reputation: 161783
ASP.NET is not magic. It doesn't magically turn the C# programming language (or any other language) into a language that is aware of web development (sessions, requests, etc).
Your code will behave exactly as it would in any other kind of application, with the addition that it can be called by multiple threads at the same time (so that using "++" is not safe).
Again, there is no magic. Just like every other application, the lifetime of a static is restricted to the lifetime of the AppDomain in which the type containing the static is loaded.
An AppDomain in an ASP.NET application is created the first time the application is accessed (unless the IIS settings force it to pre-start), and only ends at certain times, like when an assembly in the bin
folder is changed, or the web.config
is changed, or when the IIS settings say that the AppPool needs to be recycled.
Upvotes: 3
Reputation: 19037
It will increase the seed every time the constructor is invoked. Note that this can happen in multiple threads, so you better make it thread safe.
Deserialization will cause the (default) constructor to be invoked. If you serialize it to the ViewState, then ASP.NET will deserialize the object on postback, and thus invoke the constructor.
Please note that the C# language and the asp.net framework are on a whole other level. The framework is written (largely) in C#, and it will do a lot for you behind the scenes, but it still follows the rules of the language and the runtime.
Serialization is nothing more than encoding the information of an object (or graph of objects) to a stream. If you deserialize it, you will have the same information back, but it is not the same object you started with. Again, it is no magic, you could write your own serialization library using attributes and reflection.
Upvotes: 1