There are two types of caching available in ASP.NET: page output caching and data caching. From the two, page output caching is the easier to use, so let’s start with that one.
Page Output Caching
Page Output Caching simply bypasses the page life-cycle by handling a cached version of the page instead of regenerate it from scratch every time. You can cache the whole page or a portion of the page nested into a user control. To enable page output caching, simply insert the OutputCache directive after the Page (or Control) directive on the page. OutputCache has the following parameters:
- Duration: the time in seconds to cache the page.
- Location: doesn’t supported in UserControls.
- Shared: sets whether or not the cached user control should be used in multiple pages.
- SqlDependency: a table in a database on which the caching depends on.
- VarByCustom: set up custom cache dependencies (set it in the global.asax)
- VarByHeader: a semicolon-separated list of HTTP headers to cache different versions of the page.
- VarByParam: a semicolon-separated list of query string parameters to cache different versions of the page.
- VarByControl: a semicolon-separated list of control IDs to cache different versions of the page.
In today’s post, we’ll explore the various state management techniques ASP.NET provides. But first we need to underline the fact several times that HTTP is a stateless protocol. Being so, it provides huge scalability, but the programmers need to find some ways to store data (even forms) between page requests.
ASP.NET has several answers to this question:
- View State
- Query String
- Custom Cookies
- Session State
- Application State
- Control State
Now I’d like to examine the first six, because I plan to give the topic of caching a full post, and profiles are a bit different from the others.
There are a bunch of objects built into ASP.NET for providing information about the current state of the server, application, response, etc. These objects are called the ASP.NET Intrinsic Objects. You can gain access to many of them through the Page object. The Intrinsic Objects are:
ASP.NET uses HTTP Handlers to process any HTTP requests made for managed web pages. You can customize the default behavior by implementing custom handlers for custom file types. This is a process rather simple; you should do three things to accomplish it, then some debugging. All will be specified here:
- Write the code that handles the requests
- Configure IIS to pass the requests to ASP.NET
- Configure ASP.NET to process the requests by specifying file extensions
The classic example of creating a generic handler is to build an image handler. We will do the same, too. First add a new Generic Handler to your web site. This will create an .ashx file in the solution. By default, the code will be generated in the same file. This is not desired for us, because when you’ve ended, and try to run your app, it won’t work.
There are two folders specified in ASP.NET for storing code files or external assemblies. For the former, you can use the App_Code directory, for the latter, the Bin directory.
The App_Code subdirectory is used to store source code files (but not compiled code files). These files will be compiled at runtime (or during precompilation) into a single assembly. You can reference to these files (their namespaces, classes, structs, etc.) from anywhere in your application. But App_Code isn’t restricted to work with traditional source code files only. You can store XML schema (.xsd) files, for example to create a Data Access Layer. You can store .wsdl files for your Web Services respectively.
You can also use as many subfolders as you want, there is no difference in the calling syntax, because ASP.NET still compiles your folder into a single assembly. You don’t even need to set the language of the source codes stored in your App_Code folder. ASP.NET is able to identify what programming language you are using in your files, and use the compile needed. As long as you use one programming language in your App_Code folder, you don’t have to do anything.