By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,223 Members | 1,434 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,223 IT Pros & Developers. It's quick & easy.

static variables in global.asax

P: n/a
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.ma.../13/63199.aspx
----------------------------------------------------------------------------
Nov 17 '05 #1
Share this Question
Share on Google+
25 Replies


P: n/a
wrapper approach for sure in case that it requires to be thread safe in the
furture

regards
Nov 17 '05 #2

P: n/a
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
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.ma.../13/63199.aspx
-------------------------------------------------------------------------- --

Nov 17 '05 #3

P: n/a
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]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
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.ma.../13/63199.aspx
----------------------------------------------------------------------------

Nov 17 '05 #4

P: n/a
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]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
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.ma.../13/63199.aspx
----------------------------------------------------------------------------

Nov 17 '05 #5

P: n/a
Well isn't there also a consideration of what may be threadsafe ??
"Eliyahu Goldin" <re*************@monarchmed.com> wrote in message
news:Od*************@TK2MSFTNGP10.phx.gbl...
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
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.ma.../13/63199.aspx
--------------------------------------------------------------------------

--


Nov 17 '05 #6

P: n/a
For statics?
"Ashura" <As****@discussions.microsoft.com> wrote in message
news:6D**********************************@microsof t.com...
wrapper approach for sure in case that it requires to be thread safe in
the
furture

regards

Nov 17 '05 #7

P: n/a
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

"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:Oz**************@TK2MSFTNGP09.phx.gbl...
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]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
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.ma.../13/63199.aspx
----------------------------------------------------------------------------


Nov 17 '05 #8

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


"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uH**************@tk2msftngp13.phx.gbl...
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]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
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.ma.../13/63199.aspx
----------------------------------------------------------------------------


Nov 17 '05 #9

P: n/a
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:OM**************@TK2MSFTNGP10.phx.gbl...
Thanks Kevin, okay so your vote is for public static variablename rather
than get/set accessors?


"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uH**************@tk2msftngp13.phx.gbl...
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]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
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.ma.../13/63199.aspx
----------------------------------------------------------------------------



Nov 17 '05 #10

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

SM
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:OM**************@TK2MSFTNGP10.phx.gbl...
Thanks Kevin, okay so your vote is for public static variablename rather
than get/set accessors?


"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uH**************@tk2msftngp13.phx.gbl...
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]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
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.ma.../13/63199.aspx
----------------------------------------------------------------------------



Nov 17 '05 #11

P: n/a
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:e%****************@tk2msftngp13.phx.gbl...
Is multi threading/mutliple application pools a consideration? If so in
what manner?

SM
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:OM**************@TK2MSFTNGP10.phx.gbl...
Thanks Kevin, okay so your vote is for public static variablename rather
than get/set accessors?


"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uH**************@tk2msftngp13.phx.gbl...
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]" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP12.phx.gbl...
> 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.ma.../13/63199.aspx
> ----------------------------------------------------------------------------
>
>



Nov 17 '05 #12

P: n/a
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] wrote:
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.ma.../13/63199.aspx
----------------------------------------------------------------------------

Nov 17 '05 #13

P: n/a
> 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

"Randall Parker" <NOtechieSPAMpundit_please@future_avoidjunk_pundit .com>
wrote in message news:eu*************@TK2MSFTNGP15.phx.gbl... 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] wrote:
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.ma.../13/63199.aspx
----------------------------------------------------------------------------


Nov 17 '05 #14

P: n/a
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O4**************@tk2msftngp13.phx.gbl...
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:e%****************@tk2msftngp13.phx.gbl...
Is multi threading/mutliple application pools a consideration? If so in
what manner?

SM
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:OM**************@TK2MSFTNGP10.phx.gbl...
Thanks Kevin, okay so your vote is for public static variablename
rather than get/set accessors?


"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uH**************@tk2msftngp13.phx.gbl...
> 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]" <co*****************@nospam.com> wrote in message
> news:eT**************@TK2MSFTNGP12.phx.gbl...
>> 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.ma.../13/63199.aspx
>> ----------------------------------------------------------------------------
>>
>>
>
>



Nov 17 '05 #15

P: n/a
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:OB**************@TK2MSFTNGP14.phx.gbl...
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O4**************@tk2msftngp13.phx.gbl...
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:e%****************@tk2msftngp13.phx.gbl...
Is multi threading/mutliple application pools a consideration? If so in
what manner?

SM
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...
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

"Sahil Malik [MVP]" <co*****************@nospam.com> wrote in message
news:OM**************@TK2MSFTNGP10.phx.gbl...
> Thanks Kevin, okay so your vote is for public static variablename
> rather than get/set accessors?
>
>
>
>
> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:uH**************@tk2msftngp13.phx.gbl...
>> 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]" <co*****************@nospam.com> wrote in message
>> news:eT**************@TK2MSFTNGP12.phx.gbl...
>>> 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.ma.../13/63199.aspx
>>> ----------------------------------------------------------------------------
>>>
>>>
>>
>>
>
>



Nov 17 '05 #16

P: n/a
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

Nov 17 '05 #17

P: n/a
> But, arent all static variables threadsafe by
definition ?
Thats all I needed .. Thanks !! :)

- SM
"Kalpesh" <sh*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com... 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

Nov 17 '05 #18

P: n/a
On 13 Nov 2005 21:46:29 -0800, "Kalpesh" <sh*********@gmail.com>
wrote:
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.
--
Scott
http://www.OdeToCode.com/blogs/scott/
Nov 17 '05 #19

P: n/a
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
"Kalpesh" <sh*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com... 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

Nov 17 '05 #20

P: n/a
Thanks Scott for clearing my understanding

I understood that CLR takes care of thread safety, when static is
prefixed
My misunderstanding :(

Also, it is not that I do not understand the static properties (eg.
Environment.NewLine)
I am curious to understand where would you provide read/write static
properties ?
(Environment.NewLine is a read only thing)

Also, which is better, properties or methods & why ?
For eg. Outlook has ActiveInspector - which sounds like a property, but
is a method
What is the reasoning when a library developer can make something like
this as property
What is the reason for such a decision ?
In your example, Database db = Factory.DatabaseInstance doesnt allow to
change the underlying value, using singleton

Kalpesh

Nov 17 '05 #21

P: n/a
Kevin,

I do understand the difference between static & instance members
But, it is always good to learn & see with a new perspective

Thanks for explaining it in a simple manner.
I agree that developer has to take care of locking even in case of
static members

The threading guideline says
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Do not provide static methods that mutate static state.

Do make all static state thread safe.

If you must use static state, make it thread safe. In common server
scenarios, static data is shared across requests, which means multiple
threads can execute that code at the same time. For this reason it is
necessary to protect static state
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Scott cleared my confusion by his article :)

See my response to Scott on what is the purpose of static properties ?
I understand what static property is. But, dont understand the use of
it (for read/write purpose) ?
As Scott said, it can be achieved using Singleton pattern

Thanks
Kalpesh

Nov 17 '05 #22

P: n/a
Sahil,

In your case, I assume it is a readonly operation that you will be
doing (static readonly property)
So, I assume that it is threadsafe (since it doesnt allow write
operations)

Scott/Kevin: Do you agree ?

Kalpesh

Nov 17 '05 #23

P: n/a
Any data that is read-only is thread-safe.

It is important to ensure that it is read-only. This can be done with fields
by using the "readonly" modifier, as in:

public static readonly string foo = "bar";

You can also initialize the value of a static field in the static
constructor for the class that contains it:

public class foobar
{
public static readonly string foo = "bar";

static foobar
{
foo = "bar";
}
}

Another alternative is to create a private static field that is exposed by a
public static accessor.

--
HTH,

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

"Kalpesh" <sh*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Sahil,

In your case, I assume it is a readonly operation that you will be
doing (static readonly property)
So, I assume that it is threadsafe (since it doesnt allow write
operations)

Scott/Kevin: Do you agree ?

Kalpesh

Nov 17 '05 #24

P: n/a
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eV**************@tk2msftngp13.phx.gbl...
Any data that is read-only is thread-safe.


One thing to be careful of (its bitten me in the past) is that something you
think would be readonly turns out not to be.

DataView.Select was the one that bit me

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
Nov 17 '05 #25

P: n/a
On 14 Nov 2005 22:38:10 -0800, "Kalpesh" <sh*********@gmail.com>
wrote:

Also, which is better, properties or methods & why ?

I'd say it's not a choice between which is better, but which fits the
design. There are some guidelines in the following post under "General
Design Guidelines":
http://blogs.msdn.com/kcwalina/archi...28/235232.aspx

You probably won't find any static read / write properties because
it's tough to make them thread safe. You generally need a
synchronization primitive to span both the read and write operations,
which isn't possible with get and set (unless it's done in a very
dangerous way).
For eg. Outlook has ActiveInspector - which sounds like a property, but
is a method
What is the reasoning when a library developer can make something like
this as property
What is the reason for such a decision ?


Ugh - the Office object model is hideous and was designed in a
different era. I wouldn't follow it's design at all :)

--
Scott
http://www.OdeToCode.com/blogs/scott/
Nov 17 '05 #26

This discussion thread is closed

Replies have been disabled for this discussion.