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 introduces an event-handling method similar to client applications like a WPF or WF application. The main different between the classic event-handling and ASP.NET’s event-handling procedure is that in ASP.NET, a server is involved. Events are triggered in the browser, which needs to communicate them to the server. Sometimes you got to remember yourself to this fact when dealing with events.
ASP.NET server controls have a large number of predefined events, and event handling code uses the traditional .NET signature, an object, which is the sender of the event, and any event-specific information wrapped in an EventArgs class.
To understand how and when you can handle events, let’s take a look at the page events of ASP.NET:
||This event fires first when a page is being requested. You should add dynamically created controls here, or set the master page/style them programmatically here.
||Occurs when the page is initialized. The controls are initialized, but their properties don’t.
||The properties of the page are loaded back from the ViewState (or built up, if not a postback).
||Not an event you can respond, validation of controls occurs here.
||The events of the controls on the page are fired.
||Page render is running.
To help you memorize this pattern, use SILVER as your keyword.
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.