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

Use static class for caching, any negatives?

P: n/a
Bob
It seems to me that using static classes for caching as versus the
Application object has certain advantages. First, the cached values are
strongly typed, secondly, it's not ASP.NET specific so the same code can be
used for other .NET apps. I can't think of anything bad about it. I only
plan to use it for a small number of non-volatile values (but needs to be
read from DB or other sources once) so it's like I'd put everything in a
static class.

Here's a piece of sample code:

Class App {
private static XslTransform _menuXsl;

public XslTransform {
get { return _menuXsl; }
set { _menuXsl = value; }
}
}

Nov 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
It's great, though:
Remeer to use lock mechanism if needed.

" Bob" <bo*******@yahoo.com> wrote in message
news:eQ**************@TK2MSFTNGP12.phx.gbl...
It seems to me that using static classes for caching as versus the
Application object has certain advantages. First, the cached values are
strongly typed, secondly, it's not ASP.NET specific so the same code can be used for other .NET apps. I can't think of anything bad about it. I only
plan to use it for a small number of non-volatile values (but needs to be
read from DB or other sources once) so it's like I'd put everything in a
static class.

Here's a piece of sample code:

Class App {
private static XslTransform _menuXsl;

public XslTransform {
get { return _menuXsl; }
set { _menuXsl = value; }
}
}

Nov 18 '05 #2

P: n/a
HI Bob:

You certainly make good point. Just remember the Application object
does a little extra work for you by synchronizing access to the
collection using a reader / writer lock. This will prevent corruption
of the container, and allows a little more throughput than using a
regular lock / mutex.

--
Scott
http://www.OdeToCode.com

On Mon, 19 Jul 2004 12:44:23 -0500, " Bob" <bo*******@yahoo.com>
wrote:
It seems to me that using static classes for caching as versus the
Application object has certain advantages. First, the cached values are
strongly typed, secondly, it's not ASP.NET specific so the same code can be
used for other .NET apps. I can't think of anything bad about it. I only
plan to use it for a small number of non-volatile values (but needs to be
read from DB or other sources once) so it's like I'd put everything in a
static class.

Here's a piece of sample code:

Class App {
private static XslTransform _menuXsl;

public XslTransform {
get { return _menuXsl; }
set { _menuXsl = value; }
}
}


Nov 18 '05 #3

P: n/a
Bob
Isn't static members of a class thread safe by default?
"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:qb********************************@4ax.com...
HI Bob:

You certainly make good point. Just remember the Application object
does a little extra work for you by synchronizing access to the
collection using a reader / writer lock. This will prevent corruption
of the container, and allows a little more throughput than using a
regular lock / mutex.

--
Scott
http://www.OdeToCode.com

On Mon, 19 Jul 2004 12:44:23 -0500, " Bob" <bo*******@yahoo.com>
wrote:
It seems to me that using static classes for caching as versus the
Application object has certain advantages. First, the cached values are
strongly typed, secondly, it's not ASP.NET specific so the same code can beused for other .NET apps. I can't think of anything bad about it. I onlyplan to use it for a small number of non-volatile values (but needs to be
read from DB or other sources once) so it's like I'd put everything in a
static class.

Here's a piece of sample code:

Class App {
private static XslTransform _menuXsl;

public XslTransform {
get { return _menuXsl; }
set { _menuXsl = value; }
}
}

Nov 18 '05 #4

P: n/a
Hi Bob:

Some of the classes in the .NET base class library have static members
which are thread safe, but not all. Anything we would write ourselves
would not be thread safe unless we add the code to make it safe!

--s

On Mon, 19 Jul 2004 22:20:48 -0500, " Bob" <bo*******@yahoo.com>
wrote:
Isn't static members of a class thread safe by default?
"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:qb********************************@4ax.com.. .
HI Bob:

You certainly make good point. Just remember the Application object
does a little extra work for you by synchronizing access to the
collection using a reader / writer lock. This will prevent corruption
of the container, and allows a little more throughput than using a
regular lock / mutex.

--
Scott
http://www.OdeToCode.com

On Mon, 19 Jul 2004 12:44:23 -0500, " Bob" <bo*******@yahoo.com>
wrote:
>It seems to me that using static classes for caching as versus the
>Application object has certain advantages. First, the cached values are
>strongly typed, secondly, it's not ASP.NET specific so the same code canbe >used for other .NET apps. I can't think of anything bad about it. Ionly >plan to use it for a small number of non-volatile values (but needs to be
>read from DB or other sources once) so it's like I'd put everything in a
>static class.
>
>Here's a piece of sample code:
>
>Class App {
> private static XslTransform _menuXsl;
>
> public XslTransform {
> get { return _menuXsl; }
> set { _menuXsl = value; }
> }
>}
>
>


--
Scott
http://www.OdeToCode.com
Nov 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.