PostSharp.Samples / PostSharp.Samples.Caching
Project Description

This example demonstrates the use of PostSharp.Patterns.Caching.

Cache with direct invalidation

In the CustomerService class, we added the [Cache] attribute to the GetCustomer method, which automatically caches the result of the method. The cache key is built from the type name, the method name, and the method parameter id. In this class, the caching policy is set by the [CacheConfiguration] attribute on the CustomerService class. Alternatively, we could have set the policy using properties of the [Cache] attribute itself. The advantage of using the class-level [CacheConfiguration] attribute is that all cached method in the class will share that configuration setting.

Caching stuff is generally easy, but removing from the cache is generally much harder. We call this cache invalidation.

The [InvalidateCache(nameof(GetCustomer))] attribute on the top of the UpdateCustomer method means that the result of the GetCustomer method will be removed from the cache, for the specific value of the id parameter, after the UpdateCustomer methodhas successfully executed. Arguments of GetCustomer are matched at build-time against those of UpdateCustomer and you will get a build-time error in case of mismatch. Therefore the use of the [InvalidateCache] attribute is type safe.

The DeleteCustomer method shows how to perform cache invalidation imperatively by calling the CachingServices.Invalidation.Invalidate method. Calling this method is also type safe thanks to the use of a strongly typed delegate to specify which method should be removed from the cache.

The inconvenience of these two approaches is that both require the update method to know exactly which read method must be invalidated. This creates a bad separation of concerns between the read and the update layers of your code and may cause maintenance issues.

Indirect cache invalidation with dependencies

How to avoid to couple the read and update methods in regard to caching? How to ensure you don't have to modify the code of update methods when you add a read method?

The solution is to add a layer of abstraction between the read and update methods. This layer is composed of cache dependencies. PostSharp offers an object-oriented abstraction for cache dependencies. A dependency is anything that implements the ICacheDependency interface. It has a single method: GetCacheKey, which should return a string that uniquely identifies the dependency object.

Cache dependencies are illustrated in the Account and AccountServices classes.

The business object Account implements the ICacheDependency interface. The AccountServices.GetAccount method returns an Account but also calls CachingServices.CurrentContext.AddDependency(account) to specify the the GetAccount method result depends on the Account dependency.

When the UpdateAccount method calls CachingServices.Invalidation.Invalidate(account), PostSharp will remove the result of both the GetAccount methods with relevant arguments.

Now, suppose you add a read method called GetAccountsOfCustomer method, which internally calls the GetAccount method. Do you need to update UpdateAccount? No, because dependencies of each invocation of the GetAccount method are automatically added to dependencies of the GetAccountsOfCustomer method. Therefore, when the UpdateAccount method calls CachingServices.Invalidation.Invalidate(account), PostSharp invalidates the result of both GetAccount and GetAccountsOfCustomer.

As you can see, the use of dependencies improves the separation of concerns (i.e. decreases the coupling) between the reading and updating parts of your application.

However, dependencies come with some cost, as we will see in an instant.

Also note [CacheConfiguration(ProfileName = "Account")] on the AccountServices class. It says that the caching feature will be configured at run-time with a profile named Account.

Configuring the caching aspect at run time

Before you can start executing code enhanced with the [Cache] aspect, you need to configure the caching service. Most importantly, you need to specify the implementation of the storage. In this example, we will use Redis.

The run-time configuration is done in the Program.Main method.

The RedisServer.Start() command starts a local Redis server. In a real application, you don't need to do this since you will use a network server.

We then have to configure Redis as the cache storage:

var configuration = new RedisCachingBackendConfiguration
    IsLocallyCached = true,
    SupportsDependencies = true

CachingServices.DefaultBackend = RedisCachingBackend.Create(connection, configuration);

The IsLocallyCached property adds a local MemoryCache in front of the remote Redis server.

The SupportsDependency property adds support for dependencies (i.e. indirect invalidation). If you enable this dependencies with Redis, you must make sure that at least one instance of the garbage collector process runs, at any time, even when you application does not run. This is a significant burden. If you deploy your application in the cloud or in a farm, you can have two instances running in different availability groups, to make sure that at least one runs at any moment.

The following code executes the garbage collection process:

using ( RedisCacheDependencyGarbageCollector.Create(connection, configuration) )
  // ...

Finally, you need to configure the Account caching profile that we used in the AccountService class.

CachingServices.Profiles["Account"].AbsoluteExpiration = TimeSpan.FromSeconds(10);


This example demonstrated the use of the caching aspect with Redis. It showed both direct invalidation (both declarative and imperative) and indirect invalidation with dependencies.

If you run the code, you should see in the console output when cached methods are evaluated and when they are skipped.