Extending the Caching Application Block
You extend the block through designated extension points. Typically, these are custom classes, written by you, that implement a particular interface or derive from an abstract class. Because these custom classes exist in your application space, you do not have to modify or rebuild the block. Instead, you designate your extensions using configuration settings.
You can extend the block by adding a new type of backing store and storage encryption provider, by adding new expiration policies, or by replacing the default Cache Manager. The following table lists the interfaces and base classes that you can use to extend the block.
Custom Provider or Extension |
Interface or Base Class |
|---|---|
Backing Store |
IBackingStore or BaseBackingStore |
Cache Manager |
ICacheManager |
Expiration Policy |
ICacheItemExpiration |
Storage Encryption Provider |
IStorageEncryptionProvider |
For detailed information about how to integrate custom providers with the Enterprise Library configuration system and configuration tools see Creating Custom Providers for Enterprise Library.
Adding a New Backing Store
To add a new backing store, create a class that either implements the IBackingStore interface or inherits from the BaseBackingStore abstract class. You must make sure that your implementation guarantees that the backing store remains intact and functional if an exception occurs during any operation that accesses the backing store.
Because of the way the Cache object operates, you are guaranteed that any backing store will be called in a single-threaded manner. This means you do not have to make your implementation thread safe.
Adding a New Expiration Policy
The Caching Application Block lets you add your own expiration policies. You do this by building new classes that implement the following interfaces:
- ICacheItemExpiration. This interface lets developers implement their own expiration schema. It is the interface to an application-defined rule governing how and when a CacheItem object can expire.
- ICacheItemRefreshAction. This interface refreshes an expired cache item.
The ICacheItemRefreshAction interface defines the contract that must be implemented to create an object that refreshes an expired item from the cache. The implementing class must be serializable. When implementing this interface, make sure that it maintains only the required amount of environmental state. Because all portions of the environment will also be serialized, maintaining too much state can result in a huge object graph.
Replacing the Default Cache Manager
The Caching Application Block contains the class CacheManager, which is the default implementation of the ICacheManager interface. The Cache Manager loads items from the persistent backing store into memory when you instantiate the block, and it exposes the methods that applications call to add items to the cache, remove items from the cache, and get a count of the number of cached items.
Although the default Cache Manager works well for normal application caching requirements, you may want to replace it with your own implementation that changes the behavior of the Caching Application Block. The following are examples of changes you may want to make:
- Implement a distributed or specialist caching mechanism that supports different scenarios for storing and retrieving cached items that you cannot achieve just by adding a new backing store.
- Change the way that the cache manager loads the in-memory cache, perhaps so that it fetches only the most recently used items from the backing store and then fetches less recently used items on demand.
Note
For information on how to create custom providers for Enterprise Library, and to see details of alternative cache managers created by third parties, see the documentation available on the CodePlex Web site at https://www.codeplex.com/entlib/.