Caching Application Block - Enterprise Library 2.0 - IsolatedStorage and Database Caching
by David Hayden ( Florida MVP and .NET Developer )
Enterprise Library 2.0 provides a number of application blocks to help you with the plumbing in your .NET winform and web applications. I have already talked about the two most popular application blocks in Enterprise Library 2.0, the Data Access Application Block and Logging Application Block. Now I want to talk about the Caching Application Block.
I am convinced that most developers probably only use the Data Access Application Block and Logging Application Blocks in their .NET applications. In fact, the Enterprise Library Message Board sort of supports my claim if you look at the number of posts for each application block. The Data and Logging Blocks have by far more activity than the others.
Not Targeted For ASP.NET 2.0 Applications
One of the main reasons that the Caching Application Block is far less popular is because ASP.NET 2.0 has a very rich cache framework. Most web developers, like myself, will use the caching built into ASP.NET 2.0. Adding another layer / framework for caching will just needlessly complicate the application and increase maintenance costs and effort. Unless the System.Web.Caching does not provide some type of necessary caching functionality, chances are a web developer would not implement the Caching Application Block.
Winform, Smart Client, and Mixed Clients
However, if you are a winform developer, smart client developer, or have an application that runs both as a smart client and web applications, I could see the benefit of the Caching Application Block. The client caching code would be the same on both the client and the web server, but the winform / smart client apps could be configured to use IsolatedStorage or a local database for persistent cache storage and the web server could use a custom backing store that wraps HttpCache. This is a perfect example of how the Enterprise Library 2.0 application blocks hide the implementation details from the client code so that you can change the persistent caching store without causing source code changes and a recompile.
NullBackingStore, IsolatedStorageBackingStore, and DataBackingStore
Items are cached via concrete classes that derive from BaseBackingStore and/or implement IBackingStore. Enterprise Library 2.0 provides 3 caching stores:
- NullBackingStore - caches items in memory
- IsolatedStorageBackingStore - caches item in IsolatedStorage
- DataBackingStore - caches items in a database
None of them are very complex, but if you had to pick one that is the most complex, I would have to pick the DataBackingStore, since it involves a few more steps and the need for the Data Access Application Block in addition to the Caching Application Block. Why? Because, the Caching Application Block uses the Data Access Application Block when you store caching information in a database. A very smart choice to not reinvent the wheel if you ask me.
In the next steps I will demonstrate how to use a SQL Server Database as a storage for application caching information.
Step 1: The Enterprise Library 2.0 Configuration Tool
Enterprise Library 2.0 comes with a Configuration Tool that I have learned to love. It is a necessary evil to help with graphical manipulatation of configuration information that is the life blood of Enterprise Library.
If you are storing your configuration in web.config or app.config, I always recommend creating them first and then loading them with the Configuration Tool. This saves you the trouble of having to copy and paste to the web.config or app.config and I have never had a config file get corrupted yet.
Shown below is a view of the Configuration Tool complete with my settings to use a database for storing caching information. I have also included the app.config file for completeness.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="dataConfiguration"
type="Microsoft.Practices.EnterpriseLibrary.
Data.Configuration.DatabaseSettings,
Microsoft.Practices.EnterpriseLibrary.Data,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=null" />
<section name="cachingConfiguration"
type="Microsoft.Practices.EnterpriseLibrary.
Caching.Configuration.CacheManagerSettings,
Microsoft.Practices.EnterpriseLibrary.Caching,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=null" />
</configSections>
<dataConfiguration
defaultDatabase="Connection String" />
<connectionStrings>
<add name="Connection String"
connectionString="..."
providerName="System.Data.SqlClient" />
</connectionStrings>
<cachingConfiguration
defaultCacheManager="Cache Manager">
<cacheManagers>
<add expirationPollFrequencyInSeconds="60"
maximumElementsInCacheBeforeScavenging="1000"
numberToRemoveWhenScavenging="10"
backingStoreName="Data Cache Storage"
name="Cache Manager" />
</cacheManagers>
<backingStores>
<add databaseInstanceName="Connection String"
partitionName="MyApp"
encryptionProviderName="" type="Microsoft.
Practices.EnterpriseLibrary.Caching.Database.
DataBackingStore, Microsoft.Practices.
EnterpriseLibrary.Caching.Database,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=null"
name="Data Cache Storage" />
</backingStores>
</cachingConfiguration>
</configuration>
Although you could have several Cache Managers that save cache information to a different store, I have chosen to use a single cache manager to store caching information to a database.
Step 2: Creating the Database and Database Tables and Stored Procedures
You need to run a database script to create the necessary table and stored procedures to use caching on the database. The script file, CreateCachingDatabase.sql, can be found in the Scripts Directory:
Run the script and it will create a Caching Database with a CacheData Table and a few stored procedures:
Step 3: Create A Simple Winform Example
Using the above app.config pointing to the appropriate database, one can store an item in the cache using the Add Method on the default CacheManager object such as below:
using System.Windows.Forms;
using Microsoft.Practices.
EnterpriseLibrary.Caching;
namespace Caching
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender,
EventArgs e)
{
CacheManager manager =
CacheFactory.GetCacheManager();
manager.Add("Brother", "John");
}
}
}
This is the simplest implementation. There are methods for removing items from the cache as well as specifying cache durations and priorities. A quick view of the documentation as to methods of CacheManager make this obvious.
Specifying IConfigurationSource
As with the Data Access Application Block and Logging Application Block, you can specify where the Caching Application Block is supposed to get the configuration information. Below is another way to write the code above:
using System.Windows.Forms;
using Microsoft.Practices.
EnterpriseLibrary.Caching;
using Microsoft.Practices.
EnterpriseLibrary.Common.Configuration;
namespace Caching
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender,
EventArgs e)
{
IConfigurationSource source =
new SystemConfigurationSource();
CacheManagerFactory factory =
new CacheManagerFactory(source);
CacheManager manager =
factory.CreateDefault();
manager.Add("Brother", "John");
}
}
}
Conclusion
The Enterprise Library 2.0 Caching Application Block can help with improving the performance of your .NET applications. Most ASP.NET developers will leverage the built-in functionality of caching in ASP.NET 2.0. However, winform and smart client developers may see the Caching Application Block as a nice solution for their caching strategies.
Source: David Hayden ( Florida MVP and .NET Developer )
Enterprise Library 2.0 Tutorials and Examples