The argument as to whether or not to use [tag]caching [/tag] in your applications can be a lot like the argument for and against creationism. It can often be heated, and nearly always involves people who are entrenched in on one side or the other.
[tag]Performance [/tag] has always been an important consideration when designing web apps. There are many factors to be taken into account when approaching web app design from a performance perspective, but that’s not what this blog is about. For those of you with an interest in investigating further – have a look here – http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/.
Now, if you have looked at that list, you will notice that it makes reference to caching. What a coincidence!
Caching helps performance by storing in memory data which is costly to create. Caching can help remove costly and time consuming calls to a DB by storing the results of such a call in memory so that it is quickly accessible. It is inefficient to constantly recreate a web page, each time calling for data from a DB where the data required doesn’t change too often. Why not cache that data, and save on costly calls to the database? Caching helps us to be more efficient with our resources at hand.
In earlier versions of ASP.NET there were two types of caching:
[tag]Output Caching [/tag] - The entire rendered web page/User control is cached upon first visit for a specific duration. In this case the page/user control does not need to be re-rendered every time it is called, thus achieving a performance boost. This type of caching could be used, for example, when displaying a table which doesn’t change too often – e.g. Regular Customers table.
In order to implement output caching you need to add the <% @OutputCache %> directive to the top of the ASP.NET page:
<%@ OutputCache Duration=”duration” VaryByParam=”paramList” %>
The duration is the amount of seconds you wish it to remain in cache.
paramList refers to the parameter values that create variances of the information displayed eg. A Regular Customers table for a particular department. Consider a web page which displays customers dependant upon a departmentID which it receives in a querystring – you will also want the cache to reflect the department differences, otherwise it would be inaccurate.
So your <% @OutputCache %> directive could look like this, for example:
<%@ OutputCache Duration=”5000″ VaryByParam=”DepartmentID” %>
You could also vary by language, or many other parameters. To vary by all parameters, use an asterisk (*); to vary by no parameters, use “None”.
Data Caching – Using the cache API we can store data in the cache in key/value pairs. This is similar to using application state, except that the data is not stored for the lifetime of the application. [tag]Data Caching [/tag] is dependent on sufficient memory, and other dependencies which can be set by the developer. The cache is managed by ASP.NET. If we wish, we can configure application caching to notify our application when an item is removed.
It is simple to add an item to the cache:
Cache(“key”) = value ‘ VB.NET
Cache["key"] = value; // C#
And to retrieve the value:
value = Cache(“key”) ‘ VB.NET
value = Cache.Get["key"]; // C#
(see this http://aspnet.4guysfromrolla.com/articles/100902-1.aspx for further information.)
But what if you don’t want to cache the entire rendered web page? ASP.NET 2.0 introduced [tag]fragment caching [/tag] (also know as [tag]control caching [/tag]), which sets portions of a web page for caching while the rest of the page remains dynamic. These page regions must be implemented as User Controls. Then you can configure the user controls to use output caching.
ASP.NET 2.0 also introduced:
[tag]SQL cache dependencies [/tag] (allowing cache dependency on a table or row in a database. See http://msdn2.microsoft.com/en-us/library/ms178604.aspx for more information.)
[tag]Cache profiles [/tag] (allows organisation of caching behavior, such as frequently used expiry dates etc. It can be set up in web.config. See http://msdn2.microsoft.com/en-us/library/system.web.configuration.outputcacheprofile.aspx)
[tag]Post Cache Substitution [/tag] (allowing caching of the entire page with the exclusion of certain portions which remain dynamic – for example, you wouldn’t generally want your advertisement banners to be cached.)
ASP.NET 2.0 enabled developers to write their own custom cache dependencies (using the System.Web.Caching.CacheDependency class).
When I began this blog I didn’t realise how much you could write about caching. Hence the reason this article has ended up with a lot of links. I decided in the end to limit the article to a sort of overview of caching – a gentle nudge one could call it – in order to encourage the use of caching to aid application efficiency. My final word on this is that if performance is a key consideration for your application, then data caching is well worth considering. Do a search on performance on the net if you don’t believe me, and see how many times caching comes up as a key element.
I am unaware of any changes or additions to caching in .net 3.5, so if any of you have any information in this regard I’d be delighted to hear it.
Cheers, and Merry Christmas :)