Share via

When Should I Use the Caching Application Block?

  • Article

The Caching Application Block is suitable if you encounter any of the following situations:

  • You must repeatedly access static data or data that rarely changes.
  • Data access is expensive in terms of creation, access, or transportation.
  • Data must always be available, even when the source, such as a server, is not available.

You can use the Caching Application Block with any of the following application types:

  • Windows Forms
  • Windows Presentation Foundation (WPF)
  • Windows Communication Foundation (WCF)
  • Console application
  • Windows service
  • ASP.NET Web application or Web service if you need features not included in the ASP.NET cache

Scenarios for the Caching Application Block

The Caching Application Block is optimized for performance and is both thread safe and exception safe. You can extend it to include your own expiration policies and your own backing store.

The Caching Application Block is designed to work in the most common data-caching situation, which is when the application and the cache exist on the same system. This means that the cache is local and should be used only by that application. When it operates within these guidelines, the block is ideal for addressing the following scenarios:

  • The scenario requires a consistent form of caching across different application environments. For example, by using the Caching Application Block, developers can write similar code to implement caching in application components hosted in Internet Information Services (IIS), Enterprise Services, and smart client environments. Also, the same cache configuration options exist for all environments.
  • The scenario requires a configurable and persistent backing store. The Caching Application Block supports both isolated storage and database backing stores. Developers can create additional backing store providers and add them to the Caching Application Block using its configuration settings. The block can also symmetrically encrypt a cache item's data before it is persisted to a backing store.
  • The scenario requires that changing the cache configuration settings will not require application source code changes. Developers first write the code that uses one or more named caches. System operators and developers can then configure each of these named caches differently using the Enterprise Library configuration tools.
  • Cache items require any of the following expiration settings: absolute time, sliding time, extended time format (for example, every evening at midnight), file dependency, or never expired. For more information about using the expiration settings, see Design of the Expiration Process.
  • Developers want to modify the Caching Application Block source code. For more information about modifying the Caching Application Block, see Extending and Modifying the Caching Application Block.

Benefits of the Caching Application Block

When building enterprise-scale distributed applications, architects and developers are faced with many challenges. The Caching Application Block can help them to overcome some of these challenges, including the following:

  • Performance. Caching improves application performance by storing relevant data as close as possible to the data consumer. This avoids repetitive data creation, processing, and transportation.
  • Scalability. Storing information in a cache helps save resources and increases scalability as the demands on the application increase.
  • Availability. By storing data in a local cache, the application may be able to survive system failures such as network latency, Web service problems, and hardware failures.

In addition, the Caching Application Block provides a development model consistent with the other Enterprise Library Application Blocks. The Caching Application Block integrates seamlessly with the Data Access Application Block for backing store functionality. In the same manner, the Security Application Block includes caching capability that is provided by the Caching Application Block. Developers and operators configure the block using the Enterprise Library configuration tools.

Limitations of the Caching Application Block

You should deploy the Caching Application Block within a single application domain. Each application domain can have one or multiple caches, either with or without backing stores. Caches cannot be shared among different application domains.

Although you can encrypt data cached in the backing stores, the Caching Application Block does not support encryption of data that is cached in memory. If a malicious user finds a way of compromising the system and accessing the memory of your application's process, he or she would be able to access information stored in the cache. If this is a significant threat to your application, do not store sensitive information, such as credit card numbers or passwords, in the cache.

The Cache Manager can experience denial of service problems when the machine where the block is deployed runs out of memory. This can happen when a large number of items are added to the cache concurrently, when items are repeatedly added, or when large items are added with the NotRemovable option (discussed later). In a shared environment, one application can cause other applications to fail.

In addition, as the cache items in an isolated backing store are in a partially trusted location, the cache data should be encrypted before being added to the isolated storage cache. Set the correct level of IsolatedStoragePermission security policy to suit the application-specific deployment scenario. For more information on security, see Windows Presentation Foundation Partial Trust Security and Improving Web Application Security: Threats and Countermeasures on MSDN.

If you cache items in a database, keep in mind that data could be tampered with in transit between the application and the external store. Consider installing the database within the trust boundary, or encrypting the data using the encryption storage provider. Alternatively, implement Transport Level Security (TLS) between the computer running the Caching Application Block and the data store.

Alternatives to Using the Caching Application Block

Other caching solutions would be more suitable in situations such as are when there are multiple applications using the cache or when the cache and the application are not on the same system. For example, you cannot synchronize caching across a Web farm. However, you can replace the CacheManager class with a custom class if you need to fundamentally change the behavior of the block. For more information, see Extending the Caching Application Block.

Another available option is Microsoft® Windows® Server AppFabric, which provides a distributed in-memory application cache platform for developing scalable, available, and high-performance applications. A distributed cache enables your application to match increasing demand with increasing throughput by using a cache cluster that automatically manages load balancing. For more information see Introduction to Caching with Windows Server AppFabric.

ASP.NET Cache

The .NET Framework includes the ASP.NET cache in the System.Web namespace. ASP.NET application developers access this cache through the System.Web.HTTPContext.Cache object. The ASP.NET cache was developed and tuned for ASP.NET applications. However, this cache can also be used outside of an ASP.NET application by accessing the System.Web.HTTPRuntime.Cache object. The ASP.NET cache requires the System.Web assembly. Developers should verify that the assembly is supported on the required platforms and in the target environments.