I’ve been using Unity Interceptors recently, which to me are a form of AOP (Aspect-Oriented Programming). This is a cool way to put cross cutting concerns on your code in a readable, reliable and reusable manner. Typically you decorate your classes with attributes or such in order to inject code at run-time. Some typical examples of these sorts of concerns include: –
There are several frameworks out there to do AOP – PostSharp is a commercial framework which, rather than injecting code at runtime (as Unity and Castle do), actually generates the IL at compile-time, meaning that you don’t get a runtime performance hit. However, my examples in the next few posts will be with Unity as that’s what I’ve been using lately…
So, you might have a method like so: –
The idea is that when Unity creates an instance of the class that this method lives in, it notices the Transaction attribute on the method and injects some code like the following: –
Trust me – when you have lots of methods enlisting in transactions, all the TransactionScopes and using statements just get in the way.
At this point it’s probably worth saying what Unity really does – it doesn’t really inject lines of code as per the example above. It really acts as a Decorator for your class, either by: –
Generating another class which implements the same interface, doing whatever code it needs to in the generated class and then delegating the call to your class i.e. decoration.
Inheriting from your class and override virtual methods to inject code there
So if we take the former interface-based example. at runtime your code would really flow something like this: –
Again, this is a very simplistic example and not how it’s actually implemented in Unity in terms of code; you write a more generalised class known as an interceptor which Unity then injects where it requires based on the class you’re decorating.
There is obviously a (relatively small) performance hit – firstly, Unity needs to generate a new class at runtime when doing the resolve call to your interface, and secondly every call you make to that class goes through the interceptor before being delegated to the real class. However, if you’re using singletons then the first problem doesn’t really matter that much, and the second one is IMHO worth it for the gains you make in terms of clarity of code etc.
You can chain them up and inject multiple interceptors on a class; imagine having something like the following at compile-time: –
which might become something like this at runtime: –
See how those cross-cutting concerns have completely obfuscated the real intent of the code i.e. the three lines in the first example?
AOP is a great way of keeping your “real” code in your business methods, whilst putting the “other stuff” in their own place without messing your code up. This also encourages SRP i.e. each of your aspects carries out a single concern e.g. logging, event notification etc..
P.S. Yes, I know the above example doesn’t really make sense from the point of view of using a transaction – pretend it was doing some loading from the DB as well