cache at the page or at the DAL?

[sklett]

Hi-

I am having a hard time decided where I should be implementing my Cache
code. I store most of the DataSet's that I need in the Cache. I was doing
it in the bind method of my pages, but then I thought it would be cleaner to
maybe at the Cache code directly in the DAL. So, for example I might have a
DAL method to get products that looks like this:

public DataSet GetProducts()
{
if(Cache["prodData"])
{
return (DataSet)Cache["prodData"];
}
else
{
DataSet dsBuff;
//.... code to get stuff from the DB - fill the dsBuff with it

Cache["prodData"] = dsBuff;
return dsBuff;
}
}


(that was not real code, I just typed it, so if there are typos.. please
disgregard)
I'm curious if this is how you guys are doing things? Is there anything
wrong with doing it this way?

your thoughts please...

- Steve

 

[Mark Fitzpatrick]

You're probably better off to implement caching outside the DAL. If you
cache in the DAL, what happens if you need to change the caching mechanism.
You then have to verify that all the dependant functions behave properly,
not to mention you then end up with a very specific set of DAL functions.
You could implement a caching engine to call the DAL, which would unify your
caching functions and at the same time give you the flexibility to having
cached and non-cached data (or cached data that may be depednent on
different events/files/functions) from one clean DAL.

Hope this helps,
Mark Fitzpatrick
Microsoft MVP - FrontPage

 

[Kevin Spencer]

General rule of thumb: Cache your data at the scope in which it is needed.
In other words, if, for example, you have data that is not specific to any
user, but is used in many pages, cache it at the Application level. If it is
specific to a user, but used across many pages, cache it at the Session
level. If it is only used on a single Paage, either don't cache it, or cache
it in ViewState.

The principle here is to minimize memory usage, and not persist any data
that is no longer needed.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[sklett]

What I have been doing is storing all the product data (the company has 10
products, so there is not much) in a DataSet, I then cache that. When a
user chooses a product from the product listing page, I use the Select
method of a table in the DataSet to get just the data I want.

I made the site's admin all web based, when a product is added or modified,
I empty the cache, then the next time product data is needed, I hit the DB
and fill the cache again.

I hear what you are saying though. I'm just starting to have a hard time
decided if I need to even cache stuff, the traffic is so low, maybe it would
be cleaner to hit the DB each time.

Need to think and plan more

Thanks both of you for the responses, they are valuable.

-Steve

General rule of thumb: Cache your data at the scope in which it is needed.
In other words, if, for example, you have data that is not specific to any
user, but is used in many pages, cache it at the Application level. If it is
specific to a user, but used across many pages, cache it at the Session
level. If it is only used on a single Paage, either don't cache it, or cache
it in ViewState.

The principle here is to minimize memory usage, and not persist any data
that is no longer needed.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

Hi-

I am having a hard time decided where I should be implementing my Cache
code. I store most of the DataSet's that I need in the Cache. I was doing
it in the bind method of my pages, but then I thought it would be

cleaner

to
maybe at the Cache code directly in the DAL. So, for example I might

have

a
DAL method to get products that looks like this:

public DataSet GetProducts()
{
if(Cache["prodData"])
{
return (DataSet)Cache["prodData"];
}
else
{
DataSet dsBuff;
//.... code to get stuff from the DB - fill the dsBuff with it

Cache["prodData"] = dsBuff;
return dsBuff;
}
}


(that was not real code, I just typed it, so if there are typos.. please
disgregard)
I'm curious if this is how you guys are doing things? Is there anything
wrong with doing it this way?

your thoughts please...

- Steve