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.

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

How many times have you written something like this:

This is a piece of code that you might write dozens or more times to be able to use a repository to return some data to use in your application. If you’re in a hurry, it’s a quick way to get something that works, and also an easy way to get some lazy loading in place so that the repository doesn’t instantiate until you need it to. Unfortunately, this piece of code incurs technical debt. And the more you use this boilerplate elsewhere in your code, the more technical debt you incur.

There are two things in this code that are incurring the debt: hardwired dependencies and boilerplate code.

To find out how to ‘pay off’ this debt with PostSharp’s help, keep reading: 5 Ways That Postsharp Can SOLIDify Your Code: Lazy Loading of Dependencies, and keep an eye out for the next four posts.