Using PostSharp and SOLID principles, part 2

The second of my 5 part series on using PostSharp to implement SOLID principles is now live.  Here’s a little preview:

Sometimes there’s just no way to speed up an operation. Maybe it’s dependent on a service that’s on some external web server, or maybe it’s a very processor intensive operation, or maybe it’s fast by itself, but a bunch of concurrent requests would suck up all your resources. There are lots of reasons to use caching. PostSharp itself doesn’t provide a caching framework for you (again, PostSharp isn’t reinventing the wheel, it’s just making it easier to use), but it does provide you with a way to (surprise) reduce boilerplate code, stop repeating yourself, and separate concerns into their own classes.

Suppose I run a car dealership, and I need to see how much my cars are worth. I’ll use an application that looks up the blue book value given a make & model, and year. However, the blue book value (for the purposes of this demonstration) changes often, so I decide to use a web service to look up the blue book value. But, the web service is slow, and I have a lot of cars on the lot and being traded in all the time. Since I can’t make the web service any faster, let’s cache the data that it returns, so I can reduce the number of web service calls.

Since a main feature of PostSharp is intercepting a method before it is actually invoked, it should be clear that we’d start by writing a MethodInterceptionAspect…

To find out how to write a caching aspect, and some of the more advanced bits of knowledge for working with caches, continue reading: 5 Ways That Postsharp Can SOLIDify Your Code: Caching, and keep an eye out for the next three posts.