Programming Microsoft ASP.NET 4 - Dino Esposito [404]
{
return DateTime.Now.ToString();
}
Whatever string the method returns will be rendered out and becomes the output of the Substitution control. Note also that the callback method must be static and thread-safe. The HttpContext parameter to the method can be used to retrieve request parameters such as query string variables, authentication information, or personalization details.
You can also set up post-cache substitution programmatically through the WriteSubstitution method of the HttpResponse object:
Response.WriteSubstitution(
new HttpResponseSubstitutionCallback(WriteTimeStamp));
The preceding call inserts a sort of placeholder in the response, which will be replaced with the output of the method. This trick allows the AdRotator control to automatically display a new banner even on cached pages.
The use of post-cache substitution automatically enables server caching for the page output. If the page is configured for client output caching, the setting is ignored. The reason for this change lies in the fact that markup editing is necessarily a server-side operation. In addition, a page that makes use of post-cache substitution can’t rely on IIS kernel caching because ASP.NET needs to do some work before the page can be served to the user. In light of this, the page can’t just be served by IIS without first involving ASP.NET.
Note
The Substitution control can also be used in pages that don’t use output caching. In this case, the substitution callback will be called at rendering time to contribute to the response. You can think of the Substitution control as a server-side control that has the capability of expanding a placeholder to some server-side processed results.
For performance reasons, you should also avoid calling the Substitution control from within the callback. If you call it from there, the callback will maintain a reference to the control and the page containing the control. As a result, the page instance won’t be garbage-collected until the cached content expires.
Output Cache Providers
Up until ASP.NET 4, the mechanics of output cache providers was hardcoded in a system component and wasn’t exposed to developers. Most of the internal implementation of the component was public, but still there was no way to change it—take it or leave it were the only choices.
In ASP.NET 4, the component has been abstracted to a provider model (much like the model you have for session state or membership) and became replaceable by developers. When you use the code snippets shown earlier (where you don’t explicitly specify any provider information), you end up using the default provider, which delivers the same behavior as in previous versions of ASP.NET. This means that the output of pages is kept in the ASP.NET Cache object and, subsequently, in the memory of the worker process servicing the current request.
Where else would you like to store the output of ASP.NET pages on the server side? A possibility is storing the output in some permanent store, such as disk files or databases. The benefit in this case is that you release a lot of the worker process memory while gaining the chance to store much larger amounts of data on disk.
A much more enticing scenario, however, is using a distributed cache instead of a server-bound cache to store the output of pages. AppFabric Caching Services, as well as many of the commercial solutions I mentioned earlier in the chapter, offer an ASP.NET-compatible output cache provider that you roll in your application in lieu of the default one. Here’s how you change the output cache provider. It is as simple as editing a section of the web.config file:
A custom output cache provider is a class that inherits from System.Web.Caching. OutputCacheProvider which, in turn, inherits from ProviderBase. The class consists of four abstract methods, as shown here:
public abstract