David Hayden [MVP C#]

In my last post:

Simplify Caching using the Policy Injection Application Block: Aspect-Oriented Programming Opportunities

I gave an example of using the Policy Injection Application Block to remove the pre- and post-processing code that is associated with simple caching in your applications. The Policy Injection Application Block removed the clutter associated with caching from your code to better reveal its intention and simplify maintenance.

Before the Policy Injection Application Block:

public class Service : IService
{
    public Data GetData()
    {
        // Pre-Processing
        Are Results in Cache? If yes, return cached results.
        
        // Real-time Expensive Processing
        Nope. Get data from datastore.

        // Post-Processing
        Cache for X minutes and Return Results.
    }
}

After the Policy Injection Application Block:

public class Service : IService
{
    [CachingCallHandler(0, 30, 0)]
    public Data GetData()
    {   
        Get data from datastore.
    }
}

Tag Matching Rule

Using the CachingCallHandler we were able to cleanse our code, but we still need to change source code if we want to change the caching interval. Given that the caching interval on this particular method is expected to be volatile, it would be ideal to change the caching interval through meta-data in an external file that can be modified without requiring any source code changes. We also like the idea of an attribute on this method as a hint to other developers that caching is indeed happening here, but we aren't handling it in the method itself. The Tag Matching Rule in the Policy Injection Application Block provides us this wonderful capability.

Let's remove the CachingCallHandlerAttribute from the method and put a TagAttribute that will still invoke caching, but instead grab the caching interval from our Web.config file instead of in the attribute itself.

public class Service : IService
{
    [Tag("CacheResults")]
    public Data GetData()
    {   
        Get data from datastore.
    }
}

Now we will jump into the new Enterprise Library Visual Studio-Integrated Configuration Editor and configure our caching policy in the Web.config file.

Notice we still specify the interval as 30 minutes, but now it is in the Web.config where we can change it easily without changing source code and recompiling. We could have just as easily specified an external file other than Web.config as well.

The way we create this service has not changed. We still use the factory as opposed to creating it explicitly. Under the covers the Policy Injection Application Block may pass you a proxy class if it finds that you want it to intercept some method calls and do some pre- and post- processing. In this case it reads the policies in the Web.config, notices the TagAttribute on the GetData Method, and intercepts the call to do caching for you.

IService service = PolicyInjection.Create<Service,IService>();

What has changed is now we can modify the caching interval in the Web.config file without changing code. You can do it via the graphical editor or just change the XML yourself:

<add name="CachingPolicy">
    <matchingRules>
        <add match="CacheResults" name="Tag Attribute Matching Rule" />
    </matchingRules>
    <handlers>
        <add expirationTime="00:30:00" name="Caching Handler" />
    </handlers>
</add>

This is a nice way to manage caching intervals when you expect it to be volatile or you just want the option to change it via configuration.

Conclusion

Enterprise Library is a good tool for your toolbox when your applications could benefit from these types of features.

If you find yourself using the Policy Injection Application Block, there is an Effective Policy Viewer for the Policy Injection Application Block that can help you understand what policies are tied to classes when using configuration.

Don't forget about the Day of Patterns & Practices in Tampa, Florida on May 25th :) Register here.

by David Hayden