Browse DevX
Sign up for e-mail newsletters from DevX


Cache In On the Enterprise Library Caching Block for .NET 2.0

Nearly every application needs to cache data. While you're probably familiar wth the caching functionality built into ASP.NET, the Enterprise Library Caching Block provides in-memory, file-based, or database caching storage for all your other .NET applications.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

he ability to store items in memory the first time they are requested—whether data objects, pages, or parts of a page—is one of the most important factors in building high-performance, scalable applications. After storing such items in the local cache, you can improve application throughput by returning the cached output in response to subsequent requests rather than recreating them from scratch every time. Caching has the greatest performance benefit when the information requested demands significant processor time or other resources. In fact, caching is plumbing code that's too important to create, test, and maintain individually in every .NET application. Recognizing that, Microsoft has created an Application Block known as the "Enterprise Library Caching Block" (or EntLib Caching Block) that provides all the underlying cache plumbing code. This article introduces the EntLib Caching Block and provides examples showing how you can use it to create high performance .NET applications.

Caching Application Block
The EntLib Caching Block lets you incorporate local cache capabilities in your applications. You should consider using the Caching Block in any of the following situations:

  • When your application repetitively accesses relatively static data.
  • When data creation, processing and transport is expensive.
  • When high availability is a major factor.
The Caching Block lets you retrieve, add, and remove data from the cache, providing a fine level of control over the cached data through configuration of expiration and scavenging policies for the cached items. By default, the Caching Block provides three different cache store options, each of which has advantages and disadvantages, as listed below.

  1. In-memory —This is the default setting, meaning that the application will store cached items in memory. The in-memory cache is non-permanent, but provides the best possible performance compared to other caching stores.
  2. IsolatedStorage—This cache store is permanent, but slightly slower compared to in-memory. For example, you can designate an XML file or an external file as the cache store using this option.
  3. Database (via the Enterprise Library Data Access Block)—This option is similar to the IsolatedStorage option; both are slower than the in-memory option.
The required configuration for the above caching stores is both simple and straightforward; however, using the Database option involves a few extra steps, because the Caching Block uses the Data Access Block internally to communicate with the database. This article demonstrates how to use the in-memory and database caching store options. Usecase Scenarios for Caching Block
You can use the Caching Block with a wide variety of .NET application types, including Windows Forms, console applications, Windows services, Enterprise services. In addition, it is possible to use the Caching Block in an ASP.NET Web application or Web service—but you wouldn't typically take that route because of the rich caching framework already built into ASP.NET 2.0 unless the System.Web.Caching failed to provide some type of necessary caching functionality.

The 2.0 version of the Caching Block 2.0 has been redesigned to take advantage of new .NET 2.0 features. You download it as part of the Enterprise Library for .NET Framework 2.0.

Thanks for your registration, follow us on our social networks to keep up-to-date