I\'m using extensively static variables in my web application project. Now I have read from some articles that it is a global variable for the whole project and the data tha
Personally I try to avoid static variables as much as possible. They make the code difficult to unit test and also could introduce subtle bugs due to concurrent access and race conditions.
As far as your requirement is concerned you could use store the variable as a property of the control in the ViewState. If it is user specific data that you are trying to store then you could use the Session state.
For example if you have some services then you can use it as static because no need for the IIS to create repeated object for services because they all are same :)
How about using the session ..
I believe your interpretation of static is wrong.
Use the static modifier to declare a static member, which belongs to the type itself rather than to a specific object.
In other words, there is only one instance of this member for all the specific instances of the class.
There isn't anything wrong with static variables as long as you use them correctly. I believe you are mixing static with global variables. Global variables can be accessed from everywhere. This isn't desireable since knowing when and where the state of that variable is set is complex. Furthermore this makes unit testing more difficult.
This Programmers.SE question probably interests you.
On static's, there are various reasons why they should be avoided in general, although they do have their specific uses.
Then i have this requirement that a particular variable has to be initialized only once in a particular webform.aspx.cs and the scope has to be restricted to only to that particular .aspx.cs and to that particular user who has logged in ? How do i meet this requirement ? If possible can any one illustrate this with code ?
For this requirement, I would suggest you look at clarifiying the requirement:
Session
object provided by ASP. Sample code for Session
is http://msdn.microsoft.com/en-us/library/ms972429.aspxViewState
within the page. overview of ViewState is http://msdn.microsoft.com/en-us/library/ms972976.aspxPersonally I prefer using Session
- with ViewState
it's very easy for things to go wrong, and when they do go wrong it can be very hard to debug!
explanation of: "when they do go wrong it can be very hard to debug" - ViewState can be configured to works several ways, but generally it's set up to work by serializing objects into the client pages as Hidden form fields and then subsequently deserializing these objects when the page PostBack occurs. I've spent many many days debugging a certain DNN based website which had "Invalid ViewState" problems only on some browsers, only on some pages and only some of the time. What caused this? After several days I still didn't know... hence why I stay clear of ViewState if I can. However, I admit that this might be an unfair decision - in my case, I was working with a lot of third party code which generated dynamic pages and which created a lot of ViewState (size and complexity of ViewState is actually one of my reasons for not using WebForms at all if I can).