How often do I have to keep solving the same problem? As developers we’ve all been there, each project we work on we have to do the same ole’ thing we’ve done a thousand times before. Luckily in most cases there are good native features built into the language or third party frameworks that are available to reduce the tedious chore of writing basic code yet again. However, there are a lot of times when OOP doesn’t provide us with a good way to solve a recurring problem. I’m guessing since your reading the SharpCrafter’s Blog you see that this is the point where AOP steps in and fills the gap left by OOP. I recently did a video tutorial on improving exception handing using AOP via PostSharp. Traditionally in applications we need to catch when certain exceptions are thrown and do something with the exception by either logging it, calling another workflow, wrapping the exception inside of another one, or simply swallowing the exception, or some combination of all. Let’s say for example we have a class we use to call a remote web service to retrieve data for our application.
public class StockService
{
public StockDetails GetStockDetails( string symbol )
{
try
{
//.... call to service
}
catch ( SoapException ex )
{
throw new StockServiceException( "Error Getting Details", ex );
}
}
public decimal GetHistoricalPrice( string symbol )
{
try
{
//.... call to service
}
catch ( SoapException ex )
{
throw new StockServiceException( "Error Getting Historical Price", ex );
}
}
public void AddToPortfolio( string symbol, int shares )
{
try
{
//.... call to service
}
catch ( SoapException ex )
{
throw new StockServiceException( "Error Adding to portfolio", ex );
}
}
}
Look how often we are repeating the same basic pattern. We’re making our service call and wrapping any SoapException that is thrown in a custom StockServiceException. Using PostSharp we are able to modularize our code and make the business logic of the StockService class look so much cleaner.
public class StockService
{
[HandleException( SoapException, StockServiceException,
"Error Getting Details" )]
public StockDetails GetStockDetails( string symbol )
{
//.... call to service
}
[HandleException( SoapException, StockServiceException,
"Error Getting Historical Price" )]
public decimal GetHistoricalPrice( string symbol )
{
//.... call to service
}
[HandleException( SoapException, StockServiceException,
"Error Adding To Portfolio" )]
public void AddToPortfolio( string symbol, int shares )
{
//.... call to service
}
}
All we need to do is create an attribute that derives from OnMethodBoundaryAspect that accepts three parameters in the constructor; the type of exception to handle, the type of exception to wrap the caught exception in, and a message to give to the wrapped exception.
[Serializable]
public class HandleExceptionAttribute : OnExceptionAspect
{
private Type _expectedException;
private Type _wrapInException;
private string _message;
// Constructor that takes in variable parameters when the attribute is applied
public HandleExceptionAttribute( Type expectedExeptionType, Type wrapInExceptionType,
string message )
{
_expectedException = expectedExceptionType;
_wrapInException = wrapInExceptionType;
_message = message;
}
// This method checks to see if the exception that was thrown from the method the
// attribute was applied on matches the expected exception type we passed into the
// constructor of the attribute
public override Type GetExceptionType( MethodBase targetMethod )
{
return _expectedException;
}
// This method is called when we have guaranteed the exception type thrown matches the
// expected exception type passed in the constructor. It wraps the thrown exception
// into a new exception and adds the custom message that was passed into the constructor
public override void OnException( MethodExecutionArgs args )
{
args.FlowBehavior = FlowBehavior.Continue;
Exception newException = (Exception) Activator.CreateInstance(
_wrapInException, new object[] {_message, _expectedException} );
throw newException;
}
}
Another common problem set I solve with PostSharp is caching expensive method calls. I find myself repeating the same basic pattern in projects when I need to implement caching. I’m sure you’re familiar with it.
public Account GetAccount( int accountId )
{
string cacheKey = string.Format( "GetAccount_{0}", accountId );
Account account = Cache.Get( cacheKey );
if ( account == null )
{
account = accountRepository.GetAccount( accountId );
Cache.Add( cacheKey, account );
}
return account;
}
We build our cache key and check to see if the item is present if the cache. If it is we return the value pulled from the cache, otherwise we do the necessary work to retrieve/build the item to return and save it in the cache with the cache key we built so that the next time this method is called we can successfully pull the item from the cache. I’ve repeated this pattern over and over again, typically in a business layer when I need to retrieve data from an expensive resource like a database or a web service call or when I do complex logic to construct the object that I need to return. Luckily PostSharp provides a way to centralize all of the caching logic for me so I can concentrate on the business logic. The same method now looks like this
[Cache]
public Account GetAccount(int accountId)
{
return accountRepository.GetAccount(accountId);
}
Once again I simply adorn the method with an attribute and it handles a lot of the repitive code. Here is what the Cache Attribute/Aspect code looks like.
public class CacheAttribute : OnMethodBoundaryAspect
{
public override void OnEntry( MethodExecutionArgs args )
{
string key = args.Method.Name + "_" + Cache.GenerateKey( args.Arguments );
object value = Cache.Get( key );
if ( value == null )
{
args.MethodExecutionTag = key;
}
else
{
args.ReturnValue = value;
args.FlowBehavior = FlowBehavior.Return;
}
}
public override void OnSuccess( MethodExecutionArgs args )
{
string key = args.MethodExecutionTag.ToString();
Cache.Add( key, args.ReturnValue );
}
}
In the OnEntry method I’m building the cache key and checking to see if the item exists in the cache and if so I’m not letting the target method complete and I’m returning the value pulled from cache. If no item was found in the cache, the execution of the target method proceeds and when the target method successfully executes the OnSuccess override is fired and the item is stored in the cache.
There are a lot more interesting things to do with the two areas of caching and exception handling so I would encourage you to check out my screen casts to learn more.
Marcus King is a Software Engineer based in Louisville, KY. He has a broad IT background ranging from infrastructure security to software development, with years of experience working for many different sized companies, from Fortune 100 to small web startups. Marcus is passionate about performance tuning applications, developing solutions for highly scalable applications, plus is heavily involved in discovering and setting standards and best practices for software development. An Aspect-Oriented Programming (AOP) champion, Marcus regularly gives presentations on the topic. In his free time he writes applications for iPhone and Android and is on the executive committee of the codepaLOUsa developer conference in Louisville, KY.