What Is the Caching Application Block?


The Enterprise Library's Caching Application Block is an implementation of the recommendations that are put forth in the Caching Architecture Guide for .NET Framework Applications. Its design contains all of the fundamental elements found in the Solution Blueprint suggested in this guide; namely, providing implementations for CacheManagers, a cache service, and cache storage. Furthermore, the design of the Caching Application Block provides extension points that allow an enterprise to add new implementations for certain critical areas.

For example, if the cache StorageProviders (aka BackingStores) that ship with the Caching Application Block are not sufficient for the needs of a particular enterprise, a new one can be developed and "plugged in" so that it is as easy to use as the ones that ship with the block. Additionally, a simple and consistent programming interface is exposed that allows the code for an application to be written so that it is agnostic as to the type of BackingStore that is used. This allows the code for an application to remain unchanged if a modification needs to be made to the BackingStore that is used for caching. Overall, the major objective for the Caching Application Block is to provide a set of classes and interfaces that make it easy for an application to cache data to help tune that application's performance, scalability, and availability.

Performance

By storing data as close as possible to the consumer of the data, repetitive data creation, processing of the data, and data retrieval can be avoided. Reference data like countries and states are excellent candidates for information that should be cached, because this type of information rarely changes. Therefore, it can be retrieved from the backend data source less frequently and cached on an application server or Web server. This reduces or eliminates the need to make multiple roundtrips to a database to retrieve this type of data as well the need to recreate the same data for each request. Eliminating these types of activities can dramatically improve an application's performance.

Scalability

Often the same data, business functionality, and user interface fragments are required by many users and processes in an application. For example, a combo box that lets users select a specific country in a form could be used by all the users of a Web application regardless of who that user is or even where they are in the Web application. If this information is processed for each request, valuable resources are wasted recreating the same output. Instead, the page fragment can be stored in the ASP.NET output cache and reused for each request. This improves the scalability of the application because as the user base increases, the demand for server resources for these tasks remains constant and the resources that would be used to render these results can now be used for other purposes. Furthermore, this helps scale the resources of the backend database server. By storing frequently used data in a cache, fewer database requests are made, meaning that more users can be served.

Availability

Sometimes the services that provide information to an application may be unavailable. This is very common, for example, in occasionally connected smart client systems. By storing that data in another place, an application may be able to survive system failures such as Web service problems or hardware failures. Of course, this depends a lot on the type and amount of the actual data that is cached and if the application has been designed to cache information specifically to handle availability issues.

It is atypical and often inadvisable to cache all the information for an application, especially if that data is not relatively static or is transactional in nature. One exception to this rule, however, is if the application must be designed to be available even when a backend data store is not available. For example, it may be reasonable for the application to cache all of its information because the data store has scheduled periods where it may be offline or connectivity to the data source is unreliable. Each time a user requests information from the data store while it is online, the information can be returned and cached, updating the cache on each request. When the data store becomes unavailable, requests can still be serviced using the cached data until the data store comes back online.

Why Not Use the ASP.NET Cache?

We should. The .NET Framework includes support for caching in Web applications and Web services with the System.Web.Caching namespace. It should still be used to cache information in a Web application, especially when it comes to page and page fragment caching. However, there are other scenarios in which a caching mechanism that is agnostic to the runtime environment would be a valuable addition to the application to increase performance and availability. The Caching Application Block is not a replacement for the ASP.NET cache; it should be used in situations where the ASP.NET cache is not an ideal fit. The Caching Application Block is a good choice for the following circumstances.

  • For situations that require a consistent form of caching across different application environments. For example, it is a good idea to design the data layers or business layers of enterprise applications so that they can be used independently of the application environment in which they run; that is, the business or data layer can run just as well in a Windows application as it does in a Web service or Web application. Although it is possible to use the ASP.NET cache in non-Web scenarios,[2] it has not been tested and is not supported by Microsoft.

    [2] This is true for the ASP.NET cache in .NET Framework 1.1. Microsoft has tested and does support using the ASP.NET cache for non-Web scenarios for .NET Framework 2.0.

  • For smart client applications, Windows Services, and console applications that use locally cached reference data to create requests and support offline operations or need a cache to improve performance.

  • For situations that require a configurable and persistent BackingStore. The Caching Application Block supports both isolated storage and database BackingStores. This allows cached data to survive application restarts. Developers can create additional BackingStore providers and add them to the Caching Application Block using its configuration settings. The application block can also symmetrically encrypt a cache item's data before it is persisted to a BackingStore.

  • For situations that need the cache to be highly configurable so that changes to the cache configuration settings will not require application source code changes. Developers first write the code that uses one or more named caches, and then system operators and developers can configure each of these named caches differently using the Enterprise Library Configuration Tool.

  • When cache items require a combination of expiration settings for absolute time, sliding time, extended time format (e.g., every evening at midnight), file dependency, or never expired. The ASP.NET cache supports absolute time and sliding time expirations; however, it does not support setting both expirations at one time. Only one type of expiration can be set for a particular cache item. The CacheManager supports setting multiple types of cache item expirations at the same time.

The Previous Version of the Caching Application Block

There are some significant differences between the previous version of the Caching Application Block and the Enterprise Library version.

  • First and foremost, Enterprise Library's Caching Application Block is thread-safe. The earlier version of the application block could return incorrect data when multiple threads accessed a single cache item in a short period of time.

  • The earlier version supported multiple processes sharing a single cache by way of a Singleton object (via the SingletonCacheStorage). The Enterprise Library version supports using a cache in a single application domain only.

  • The ICacheStorage interface has been replaced with the IBackingStore interface. Persistent storage in a database is provided through its dependency on the Data Access Application Block. Isolated storage is supported for persistent storage via the new IsolatedStorageBackingStore. The application block does not, however, include support for memory-mapped files.

  • The earlier version included the scavenging algorithm as a pluggable provider. In the Enterprise Library version, you must modify the application block source code to change the scavenging algorithm.

  • The earlier version included encryption as a pluggable provider. The encryption of cache item data in the Enterprise Library version is provided by the Cryptography Application Block.




Fenster Effective Use of Microsoft Enterprise Library(c) Building Blocks for Creating Enterprise Applications and Services 2006
Effective Use of Microsoft Enterprise Library: Building Blocks for Creating Enterprise Applications and Services
ISBN: 0321334213
EAN: 2147483647
Year: 2004
Pages: 103
Authors: Len Fenster

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net