ASP.NET Caching Strategies (Cont.) The Namespaces (System.Web and System.Web.Caching) There are two namespaces containing ASP.NET caching classes: System.Web and System.Web.Caching. Caching-related classes found inside System.Web are used to cache Web pages and portions of Web pages. The System.Web.Caching class provides developers direct access to the cache, which is useful for putting application data into the cache, removing items from the cache and responding to cache-related events. Table 1 provides a quick reference to the various classes used in ASP.NET caching strategies. Cacheability (Cache on the Client/Server) Before a page can be cached, you must indicate its "cacheability." Setting this parameter indicates the devices on which your page can be cached. Valid devices include the client making the request, the server fulfilling the request, proxy servers, etc. To indicate a page's cacheability, you use the following method call at the top of your page: Page.Response.Cache.SetCacheability( _ HttpCacheability.Server)
The SetCacheability method takes a member of the HttpCacheability enumeration as its only parameter. The members of this enumeration are designed to allow you to control where your page is cached. Table 2 presents the details for each enumeration member. Version Caching (Versions of Pages) Dynamically generated pages are typically created based on a set of parameters sent either to the page in the form of querystring parameters or posted using form fields and a submit button. ASP.NET makes it easy to cache these pages as well. The key to caching these pages is to cache versions of the page. That is, one version of the page for each value for a given parameter (or set of parameters). | " | The duration parameter in the example code represents the number of seconds the page should remain in the output cache before being refreshed.
| " |
For example, suppose our hypothetical regional sales report allows users to filter the data they view by month. Imagine the month parameter is passed to the page via the querystring. If we indicate that the page is cached, but do not cache based on this parameter, then only calls to the page without the querystring parameter will be cached. Each call using the querystring will override the cache and cause the page to execute its code rather than pull from cache. Of course this is not the caching behavior you want. Instead, each call to the page with a new month should result in a new page added to the cache as its own separate item. This way, subsequent requests for the same month can be delivered from the cache. .NET makes version caching rather simple via the HttpCacheVaryByParams class. This class is accessed by a property exposed by Response.Cache. For example, the following code indicates that the page should cache versions of itself based on the Month querystring parameter. Page.Response.Cache.VaryByParams( _ "Month") = True
You'll be happy to know that the same line of code works for parameters posted to the page. For instance, if you submit the month data to the page based on a user form field (text box, dropdown, etc.) with the same name of "month," then the same line of code results in multiple cached versions of the page. Of course, pages are often rendered based on more than one parameter. For instance, both month and region might be parameters in our example. Each combination of month and region should result in a separate page being added to the cache. You can indicate a group of parameters on which to base caching for a given page using the same VaryByParams property. To do so, you simply separate each parameter with a semicolon, for example: Page.Response.Cache.VaryByParams( _ "Month;Region") = True
You can also indicate that a page should be added to the cache based on all its parameters. To do this, you use an asterisk (*) as the VaryByParam value. | & | | Code-Behind Classes
In this article, we talk a lot about implementing caching policies procedurally inside of your 'code-behind' classes. Code-behind classes are a new concept introduced with ASP.NET. Put simply, these are classes programmatically tied to an ASP page. The beauty of code-behind classes is that, for the first time, it is possible to physically separate code responsible for presentation and logic, without ever leaving the ASP.NET design environment. In other words, HTML and script developers are free to set the "look and feel" of the page by dealing solely with the .aspx page, while VB/C# developers can concentrate on the core logic by working with the code-behind class. The code becomes much more readable using this method of programming - no more in-line code scattered throughout the HTML - and it allows developers and designers to work side-by-side without trampling on each others' code base. One tip to remember: To see the code-behind files in Visual Studio, you may have to click the Show All Files button at the top of the Solution Explorer pane. |