Caching

Caching is a programming technique that, when used properly, can help you improve the performance and startup time of your application. Caching allows you to store data that is frequently used or costly to retrieve so that it can be accessed faster.

In this chapter, we’ll take a look at the new Caching Application Block from the Enterprise Library Silverlight Integration Pack. Since this is a new application block that does not build upon the caching application block from Enterprise Library 5.0, we’ll also look at the API that this block offers. We’ll look at how different caching strategies, such as reactive and proactive caching, were implemented in the Stock Trader V2 reference implementation. At the end of this chapter, we’ll show various examples of how to use the Caching Application Block.

Caching Using the Caching Application Block

The new Caching Application Block provides a consistent API for adding and retrieving items from a cache. The following code shows how you can use the cache from C#.

object item = cache["Item"];
if (item == null)
{
    item = CreateItem();
    cache.Set("Item", item, 
        new CacheItemPolicy { AbsoluteExpiration = DateTime.Now.AddHours(2) });
}

Using the configuration editor, you can define what type of cache you’d like to use. The Caching Application Block allows you to store cached values in memory or in isolated storage:

Caching Considerations in a Silverlight Application

If you decide to apply caching in a Microsoft® Silverlight® browser plug-in application, there are several things you'll need to take into consideration.

Memory Is Not Shared with Other Users

Caching in a Silverlight application is somewhat different from caching in a web application. In a web application, the memory of the server and the cached data is typically shared by potentially hundreds of users. Because of that, you'll prefer to cache items that are used by many users. You'll also want to limit the size of the cache, because server memory is also needed to handle requests from all the users.

A Silverlight application is only used by a single user. This means that you don't have to share the client computer's memory with potentially hundreds of users. Unless your application works with really large data sets, the size of the cache in memory is usually not a constraint.

Isolated Storage Size Limit

In a normal Silverlight application, if you wish to store cached data in a persistent way, you can store it in isolated storage. By default, the isolated storage quota is limited to 1 Mb per domain. This means that the isolated storage quota is shared between all applications downloaded from a particular domain name, such as www.microsoft.com. 1 Mb is usually enough space just for caching, but if you decide to use isolated storage to store other information, such as log information, then you can quickly run out of space. While it is possible to increase the size of isolated storage, this must be explicitly allowed by the end user. In a corporate environment, it is also possible to increase the size of the quota for a particular application by using a Microsoft .NET Framework security policy.

For most Silverlight applications, this means that you cannot rely on the fact that the isolated storage quota has been increased. If your application needs more space in isolated storage, then you should make this clear to your users (so they won't decide to deny your application extra space) but you should also ensure that your application will work with minimal isolated storage space.

For more information about isolated storage, please read this topic on MSDN®.

Browser Caching

For certain types of web requests, the result is cached by the browser cache. For example, the WebClient class uses the browser cache. On the server you can use the System.Web.HttpCachePolicy class to specify how a particular page should be cached by the browser.

Not all server requests are cached by the browser. For example, requests made by Windows® Communication Foundation (WCF), WCF RIA Services or WCF Data Services bypass the browser cache. In those cases, you'll need to cache the results manually.

So for certain types of requests, you can use the browser cache to give you a transparent, server-controlled caching mechanism.

Server-Controlled Cache Expiration Is Difficult to Implement

Silverlight applications usually don't have a continuous connection to the server. This makes it difficult for a Silverlight client to detect when something has changed on the server that should invalidate certain values in the Silverlight application's cache. For example, in ASP.NET it is possible to use the Microsoft SQL Server® cache dependency to invalidate a cached item when the underlying data has changed.

In Silverlight this would be difficult to achieve, because the web server would then need to notify all its clients that a particular piece of data has changed.

Next Topic | Previous Topic | Home

Last built: July 8, 2011