static variables in global.asax

[Sahil Malik [MVP]]

So here's a rather simple question.

Say in an ASP.NET application, I wish to share common constants as static
variables in global.asax (I know there's web.config bla bla .. but lets just
say I wanna use global.asax) ---

Would you declare your static var as ---

public static int x ;

or would you wrap it up in an accessor property as ---

private static int x ;
public static int X
{
get { return x ; }
}

.... and why?

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------

 

[Guest]

wrapper approach for sure in case that it requires to be thread safe in the
furture

regards

 

[Eliyahu Goldin]

It's a matter of your programming style. Some programmers, including myself,
prefer not to expose variable members and provide access via properties.
Otherwise there is nothing wrong with the first form.

Eliyahu

 

[Peter Rilling]

Either way if fine, if no code has to validate the variable X. Obviously
wrapping it in a property is more flexible.

Now, the questions, why put it in global.asax? If it were me, I would
create my own class that had the variables defined.

 

[Kevin Spencer]

The global.asax file is a class definition. Static fields and properties
(*not* "variables") may be declared as members of any class, and may be
referenced by any other member of any other class in any assembly in any
application, as long as they are declared to be public, and as long as the
assembly containing the class which contains the static members is
referenced by any assembly having classes with members that may need to
access those fields.

Therefore, it matters not what class defintion you declare your static
members in, as long as that class is part of the application, and is
referenced by any other assemblies that may need access to it.

As to whether the field should or should not be accessed from outside the
class only by a property get accessor, there are a few considerations to
keep in mind:

1. Is there any additional processing necessary
to be performed when the field is accessed?
2. Is there, in fact, an existing field to be accessed?
Some properties return calculated data, not member data.
3. Are there any other factors which might justify the indirection
involved in accessing the data through a get accessor?
a. Programming Conventions: In some teams, this is a convention,
for various reasons, such as (b) below.
b. Extensibility. It is easier to extend a property than a field,
if necessary. It does not break the API to change the return value.

There may be factors which I didn't think of, but these cover the major
ones.

 

[Sahil Malik [MVP]]

For statics?

 

[Sahil Malik [MVP]]

Well isn't there also a consideration of what may be threadsafe ??

 

[Sahil Malik [MVP]]

Well .. either cannot be fine .. it may be fine for constants, but not for
read-write variables.

Not arguing the fact that global.asax isn't the best place for them .. I am
just arguing from a academic point of view.

- SM

Either way if fine, if no code has to validate the variable X. Obviously
wrapping it in a property is more flexible.

Now, the questions, why put it in global.asax? If it were me, I would
create my own class that had the variables defined.

 

[Sahil Malik [MVP]]

Thanks Kevin, okay so your vote is for public static variablename rather
than get/set accessors?

The global.asax file is a class definition. Static fields and properties
(*not* "variables") may be declared as members of any class, and may be
referenced by any other member of any other class in any assembly in any
application, as long as they are declared to be public, and as long as the
assembly containing the class which contains the static members is
referenced by any assembly having classes with members that may need to
access those fields.

Therefore, it matters not what class defintion you declare your static
members in, as long as that class is part of the application, and is
referenced by any other assemblies that may need access to it.

As to whether the field should or should not be accessed from outside the
class only by a property get accessor, there are a few considerations to
keep in mind:

1. Is there any additional processing necessary
to be performed when the field is accessed?
2. Is there, in fact, an existing field to be accessed?
Some properties return calculated data, not member data.
3. Are there any other factors which might justify the indirection
involved in accessing the data through a get accessor?
a. Programming Conventions: In some teams, this is a convention,
for various reasons, such as (b) below.
b. Extensibility. It is easier to extend a property than a field,
if necessary. It does not break the API to change the return value.

There may be factors which I didn't think of, but these cover the major
ones.

 

[Kevin Spencer]

I wish it were that simple, Sahid.

My vote is to use whatever is appropriate, keeping the considerations I
enumerated in mind.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

Thanks Kevin, okay so your vote is for public static variablename rather
than get/set accessors?

 

[Sahil Malik [MVP]]

Is multi threading/mutliple application pools a consideration? If so in what
manner?

SM

 

[Kevin Spencer]

Hi Sahil,

Multi-threading is definitely not, as far as whether to use fields or
properties is concerned. As for multiple application pools, there is only
one application pool used by each application.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

 

[Randall Parker]

I'd access it thru an accessor on the small chance that due to requirements changes
some day it would either:

A) get dynamically calculated from other fields that change.

B) get accessed from a database or other configuration store.

Also, I'd question putting it in global.asax in case you wanted to use it across
applications. Why put something in global.asax unless there is a compelling reason to
do so?

 

[Sahil Malik [MVP]]

Also, I'd question putting it in global.asax in case you wanted to use it

across applications. Why put something in global.asax unless there is a
compelling reason to do so?

Sure .. I am not arguing that. I am just asking from an academic point of
view.

SM

 

[Sahil Malik [MVP]]

Okay multiple applications in one single app pool - all accessing the same
static in the global.asax --- would that be a matter of concern in making
this choice?

Sorry I'm being bothersome but I really do want to understand this. It is my
understanding that in non-asp.net apps atleast, you should put get/set
accessors on non-statics and vice versa on statics. I am wondering if the
same holds true for global.asax in ASP.NET

- Sahil Malik

 

[Kevin Spencer]

You're not being bothersome. But you do need to study up on the answers
you've been given until you understand what's going on. It sounds like you
want to. Getting an answer to a question only points to the reasons behind
the answer. The reasons behind answer the question and future questions. I
read in the .Net SDK, the W3C.org web site, and a slew of others every day
of my professional life, and most of my free time as well, and I never seem
to know enough! Fortunately, this stuff fascinates me, so I'm having a good
time.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

 

[Kalpesh]

Hi,

Sorry to jump in between. But, arent all static variables threadsafe by
definition ?
And, what does it mean to have static property ?

Property = state (atleast some kind of state)
Correct me if I am wrong in my understanding.

Kalpesh

 

[Sahil Malik [MVP]]

But, arent all static variables threadsafe by

definition ?

Thats all I needed .. Thanks !!

- SM

 

[Scott Allen]

Hi,

Sorry to jump in between. But, arent all static variables threadsafe by
definition ?

No. Many of the static members in the .NET library are thread-safe,
but only because Microsoft made the extra effort to synchronize
threads.

See:
http://odetocode.com/Articles/313.aspx and
http://odetocode.com/Articles/314.aspx

And, what does it mean to have static property ?

It means the property is associated with the Type, and not an instance
of the Type. Some people implement a Singleton pattern using a static
property:

Database db = Factory.DatabaseInstance;

where Factory is a class name, not an instance of the class.

 

[Kevin Spencer]

Hi Kalpesh,

Okay, you start out with the question:

But, arent all static variables threadsafe by
definition ?

This is followed up by the question:

And, what does it mean to have static property ?

So, from the second question, you admittedly don't know what "static" means.
Therefore, how could you presume that the first question has any basis
whatsoever? Just curious!

The "static" modifier indicates that a member (not "variable" - a variable
only has method scope, and static variables are disallowed in .Net) is never
instantiated. To understand instantiation, it helps to know a little about
the programming stack and the programming heap. The heap is where code is
loaded when an assembly is loaded. It is basically a copy of the code from
the assembly DLL. There is a single copy of the code loaded at run-time, and
typically, when an object is instantiated, a copy of the code from the heap
is placed in a region of memory called the "stack." It is called this
because the copy only exists as long as it is in use. When it goes out of
scope (for example, when a function exits, or a class is no longer in use),
the copy of the code is removed from the stack. Thus, you can have many
instances of classes, members, and yes, variables, on the stack. Each
instance is separate, and may (in fact, usually does) have completely
different values in it than any other instance.

A static member is one which is never instantiated. Rather than putting a
copy of it on the stack, the original single copy of the DLL code is used in
the heap. Thus, static members are referred to as "singletons." Any class,
or member of a class, can access the static member, as long as it is given
the accessibility that is needed by the member that wants to use it.

Since the static member is a single "instance," there is nothing necessarily
thread-safe about it. Static data that is "read only" is thread-safe. This
includes static methods. But any object that attempts to change static data
may run into an issue, as other objects may be reading it or attempting to
modify it at the same time. This can lead to unexpected and disastrous
results. Locking is useful in this regard, as it prevents more than one
object from accessing it at any one time.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition