<= Home
Mechanics of Applying Aspects in .NET 101
Obviously it is foremost important to first know what AOP is and to be able identify the crosscutting concerns you wish to make into an aspect. Clearly communicating these concepts of AOP can be difficult on their own, but then applying aspects can be quite confusing. Most likely this is true because of out the major (in the sense of shear amount of developers using them) languages (i.e. Java/C++/C#) there is no 1 way of doing aspect oriented software development. Every language or platform has its unique framework(s) with its unique syntax.
.NET is relatively in it’s infant stage when it comes to AOP. Unlike Java, .NET lacks mature AOP frameworks like AspectJ and JBoss. Java even has published books on using these frameworks, while the .NET developer community has to open up the code of its frameworks because the developers that created them provide hardly any documentation (I am guilty as well).
There are two main approaches out there to apply aspects in .NET. The high level categorization is runtime and compile time.
Runtime aspects get applied during the execution of a program. In this case it is a lot more dynamic applying aspects. Most often aspects are applied through declarations in external configuration files allowing you to weave new behavior in with out re-compiling. Unfortunately in .NET runtime aspect framework implementations have performance issues associated with them.
Applying runtime aspects is tricky but primarily the main way of doing so is by taking an instance of an object and creating a proxy of it (think remoting). Lets say we have object A which has a method DoSomething()…normally we would invoke DoSomething() directly on object A, but to apply aspects what we do is proxy object A with a new object, we can call B. The functionality is implemented by AOP frameworks using reflection and emitting IL code during runtime. To our system object B looks like object A, but when we invoke DoSomething() on object B, it first intercepts that call, allows aspects to be executed and then invokes the real method DoSomething() on object A. Encase uses this concept for AOP.
The other option to runtime aspect weaving applies and invokes aspects when a method is being JIT-ed. This is really how your code profiler tools work, by intercepting the JIT of a method and applying a profiler-esque aspect. An example of this approach is LOOM.