Programming Microsoft ASP.NET 4 - Dino Esposito [384]
Let’s start reviewing the original limitations of CacheDependency that have led to removing the sealed attribute on the class, making it fully inheritable.
Extensions to the CacheDependency Base Class
To fully support derived classes and to facilitate their integration into the ASP.NET caching infrastructure, a bunch of new public and protected members have been added to the CacheDependency class. They are summarized in Table 18-6.
Table 18-6. Public and Protected Members of CacheDependency
Member
Description
DependencyDispose
Protected method. It releases the resources used by the class.
GetUniqueID
Public method. It retrieves a unique string identifier for the object.
NotifyDependencyChanged
Protected method. It notifies the base class that the dependency represented by this object has changed.
SetUtcLastModified
Protected method. It marks the time when a dependency last changed.
UtcLastModified
Public read-only property. It gets the time when the dependency was last changed.
As mentioned, a custom dependency class relies on its parent for any interaction with the Cache object. The NotifyDependencyChanged method is called by classes that inherit CacheDependency to tell the base class that the dependent item has changed. In response, the base class updates the values of the HasChanged and UtcLastModified properties. Any cleanup code needed when the custom cache dependency object is dismissed should go into the DependencyDispose method.
Getting Change Notifications
As you might have noticed, nothing in the public interface of the base CacheDependency class allows you to insert code to check whether a given condition—the heart of the dependency—is met. Why is this? The CacheDependency class was designed to support only a limited set of well-known dependencies—against files, time, and other cached items.
To detect file changes, the CacheDependency object internally sets up a file monitor object and receives a call from it whenever the monitored file or directory changes. The CacheDependency class creates a FileSystemWatcher object and passes it an event handler. A similar approach is used to establish a programmatic link between the CacheDependency object and the Cache object and its items. The Cache object invokes a CacheDependency internal method when one of the monitored items changes. What does this all mean to the developer?
A custom dependency object must be able to receive notifications from the external data source it is monitoring. In most cases, this is really complicated if you can’t bind to existing notification mechanisms (such as file system monitor or SQL Server notifications). When the notification of a change in the source is detected, the dependency uses the parent’s infrastructure to notify the cache of the event. We’ll consider a practical example in a moment.
The AggregateCacheDependency Class
Not only can you create a single dependency on an entry, you can also aggregate dependencies. For example, you can make a cache entry dependent on both a disk file and a SQL Server table. The following code snippet shows how to create a cache entry, named MyData, that is dependent on two different files:
// Creates an array of CacheDependency objects
CacheDependency dep1 = new CacheDependency(fileName1);
CacheDependency dep2 = new CacheDependency(fileName2);
CacheDependency deps[] = {dep1, dep2};
// Creates an aggregate object
AggregateCacheDependency aggDep = new AggregateCacheDependency();
aggDep.Add(deps);
Cache.Insert("MyData", data, aggDep)
Any custom cache dependency object (including SqlCacheDependency) inherits CacheDependency, so the array of dependencies can contain virtually any type of dependency.
The AggregateCacheDependency class is built as a custom