views:

6960

answers:

3

I would like to cache my most database heavy actions in my asp.net-mvc site. In my research I have found

But I don't feel I get it yet.
I want to be able to cache my POST request depending on several pars. These pars are in an object. So I would like to cache the result of the following request:

public ActionResult AdvancedSearch(SearchBag searchBag)

Where searchBag is an object that holds (a bunch) of optional search parameters. My views themselves are light (as they should be), but the data access can be rather time consuming, depending on what fields are filled in in the search bag.

I have the feeling I should be caching on my datalayer, rather then on my actions.
How am I supposed to use the VaryByParam in the OutputCache attribute?

+16  A: 

I like to cache in the model or data layer as well. This isolates everything to do with retrieving data from the controller/presentation. You can access the ASP.NET cache from System.Web.HttpContext.Current.Cache or use the Caching Application Block from the Enterprise Library. Create your key for the cached data from the parameters for the query. Be sure to invalidate the cache when you update the data.

Matthew
I should read up on the Enterprise Library I think.Since most of the delay lies at the Data Layer I guess that will be the best solution in the end. Currently it is a read-only DB, so this eleviates the stale object problem :)
borisCallens
The caching app block seems like a whole mess of overkill. I've found that in almost every instance that HttpRuntime.Cache is more than adequate.
Jeff Putz
Why overkill? I'm now a lot further into the development and I've found the EL's cache system really easy to use. Reference the correct library, add the correct config lines and you can start caching and retrieving objects with one line of code each.
borisCallens
+11  A: 

Or you can be independent of the HttpContext.Current and access Cache from HttpRuntime.Cache :)

Andrei Rinea
+3  A: 

Often, OutputCaching can be the most fast and efficient, but only when it meets your requirements. No point in having fast efficient if it's wrong! ;)

In this case, it sounds like caching at the data layer is correct because you have complex caching needs. Sometimes, you can combine the two if the set of parameters which control what output is cached is simple.

Haacked