I have read another AOP article on code project today which uses context bound objects as a mechanism to implement the interception of method calls. The article does a fairly good job on describing the use of context bound model under .NET, it is however a little bit misleading as it defines the aspect oriented programming as “interception technology that enables some code to run before/after a method call or just instead of it”.
I would like to point out that aspect oriented programming is actually not interception, as Ted Neward concludes in his excellent article. The interception is actually only a help construction (tn: “underlaying plumbing”) which .NET AOP systems use due to the lack of programming language level support.
Neverthanless is the interceptor an interessting architectural pattern, which can be observed in many frameworks which are not necessary related to aop.
There are many ways to implement the interception with .NET. In this article I will try to summarize some of them:
1. Code Generation
The simplest and perhaps the most straight forward way to implement something like this is just to use a generator and generate the code you need at the right places. Not very elegant, but still an alternative for smaller problems. If you want to use code generation you may want to test codesmith, the template based code generator with visual studio integration.
2. Context bound objects
The .NET Framework implements with context bound objects the interception architecture with two proxy-classes (transparent and real proxy) and marshalling (message sinks). The architecture is very similar to the the one used when performing remote calls across application domain boundaries. This article provides a good starting point if you want to learn how to implement an interception based service.
Interception Architecture [3]
The use of context bound objects for AOP purposes is described in this article.
3. Proxy classes
If you don’t want to use the full fledged interception architecture of context bound objects you may consider implementing a simpler model. One way is the (dynamic) generation of proxy classes. This can be done with reflection and reflection emit. The easier way to generate the proxy classes at runtime is to use the managed wrapper of csharp compiler. There are some aop tools like LOOM.NET which use this approach.
4. Code Enhancement
The modification of IL code (pretty obscure, I agree…) is called “code enhancement”. Some object relational mapping tools use interception of field calls to mark the objects dirty. These tools replace the field calls with generated method calls at IL-level. For example: if we have a class Cat with property _name , every setfld (set field) IL instruction would be replaced with a generated IL equivalent of following code :
public void _setName (string val)
{
ChangeTracker.AddObject (this);
_name = val;
}5. The .NET Profiling API
provides the possibility to intercept almost everything in CLR, like assembly loading/unloading, method calls, exception handling etc. The use of profiling API is described in .NET Framework SDK documentation or in this MSDN article. It is not a very confortable thing to use: you have to implement the ICorProfilerInfo COM interface, and set some environment variables. The obvious drawback of the approach is also that it affects the whole CLR. There were some attempts to implement aop tools with .NET profiling api like claw.net.
[1] Neward, T. – Setting the story straight: AOP != Interception
[2] Code Smith – The template based code generator.
[3] Lowy, J. – Contexts in .NET – Decouple Components by Injecting custom services in interception chain
