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. PerformanceBy 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. ScalabilityOften 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. AvailabilitySometimes 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.
The Previous Version of the Caching Application BlockThere are some significant differences between the previous version of the Caching Application Block and the Enterprise Library version.
|