AOP (Aspect Oriented Programming) in C#
I have been looking at some of the AOP implementations for C# and compared to what we have seen in Java (Eg: AspectJ, Aspectwerkz, Spring AOP, JBoss AOP etc..), the playing field on the .NET side is still not mature enough regarding AOSD.
Having said that, the exploration that is currently happening is quite interesting! The AOP implementations for C# (hence .NET in general) are not only trying to apply the known implementation patterns from the Java side but are also trying to deviate/differentiate from those in their own way.
But most of them are revolving around Static build time code-weaving and/or attributes+interception modes. I should say that I still have not seen any runtime interception engines.
We should also differentiate between classic AOP philosophy vs a plain interception pattern. AOP is not just about being able to hijack specific events (ex: Method entry/exit) of predefined code.. it is about introducing crosscutting concerns into the main body of code at any point. Ted Neward wrote a very good article about the distinction that can be found here
Just to put things in perspective:
1. Build time code-weaving means that the cross cutting concerns are defined external to the class that needs interception (Either through XML or through some programming language .. either C# or a custom dialect). Then when the code is compiled, the compiler of the AOP implementation will "weave" necessary code right into the IL for the class that needs interception along with the necessary references from the AOP engine to support runtime execution of weaved code by .NET runtime. Then .NET runtime will execute the weaved byte code just like any other normal .NET code. It should be noted that this is the closest pattern to AspectJ on the Java side.
An example of such an engine is EOS (and there are some more), an academic contribution for AOP in C#.
(I will add more detail to how EOS does this, later! :-)
IMHO, although this pattern can be made to be very less intrusive from a development perspective (by cleanly separating the intrumented code from instrumentation), it still has implications in terms of having to change code (although the aspects, not the intercepted classes), build and run.. when we need to add/modify the existing interceptions.
But this is the most prevalent and widely accepted AOP pattern, even in the Java side.. So I can live with it! :-)
2. There are some more implementations which use C# attributes to define custom attributes specific to the AOP engine. Then the classes that need to be intercepted will be decorated with these custom attributes. (And will necessarily become Context Bound Objects). So the AOP engine's custom attribute implementation can take over the specifics of interception for these context bound objects at runtime. Now this pattern is neither truly build time or runtime as it is both! :-)
But IMHO, this does not reflect the true/complete spirit of aspect oriented software development practices as we still need to identify/mark the classes that need to be intercepted, at coding time! Hence if we need to another class to be intercepted or drop one that is decorated.. you guessed it, we need to change the code.. compile.. run.. the whole nine yards.
(Will add examples of frameworks that do this and the ways they do it.. later!)
3. Now I have not seen any implementations on the C# side along these lines but this pattern of runtime weaving will be able to intercept the classes that need to be weaved, at runtime without any need for byte code manipulation at build time. Of course this would need a way to either override the classloader and/or be able to generate proxies/stand-ins for classes that need to be instrumented with necessary interception code in them and push the execution through these generated objects, at runtime! One the .NET side, this would mean extensive use of Reflection.Emit and proxy classes concepts (and some other innovative ways of handing some subtleties)!
AspectWerkz on the Java side has been a pioneer in this area of runtime weaving and "on the fly" compilation of join points.
This pattern with a little bit of necessary support at build time coupled with declarative aspect definitions would constitute my best choice for AOP. But again, that would have performance implications as no matter how much we optimize, runtime code weaving will be at least a tad bit costlier than build time weaving!
(Will add details about how AspectWerkz does this.. and any potential implementations on the C# side that are trying to embrace this.. later!)
So there it is! A short story about AOP progress and primer on the .NET side!
Any thoughts?
Having said that, the exploration that is currently happening is quite interesting! The AOP implementations for C# (hence .NET in general) are not only trying to apply the known implementation patterns from the Java side but are also trying to deviate/differentiate from those in their own way.
But most of them are revolving around Static build time code-weaving and/or attributes+interception modes. I should say that I still have not seen any runtime interception engines.
We should also differentiate between classic AOP philosophy vs a plain interception pattern. AOP is not just about being able to hijack specific events (ex: Method entry/exit) of predefined code.. it is about introducing crosscutting concerns into the main body of code at any point. Ted Neward wrote a very good article about the distinction that can be found here
Just to put things in perspective:
1. Build time code-weaving means that the cross cutting concerns are defined external to the class that needs interception (Either through XML or through some programming language .. either C# or a custom dialect). Then when the code is compiled, the compiler of the AOP implementation will "weave" necessary code right into the IL for the class that needs interception along with the necessary references from the AOP engine to support runtime execution of weaved code by .NET runtime. Then .NET runtime will execute the weaved byte code just like any other normal .NET code. It should be noted that this is the closest pattern to AspectJ on the Java side.
An example of such an engine is EOS (and there are some more), an academic contribution for AOP in C#.
(I will add more detail to how EOS does this, later! :-)
IMHO, although this pattern can be made to be very less intrusive from a development perspective (by cleanly separating the intrumented code from instrumentation), it still has implications in terms of having to change code (although the aspects, not the intercepted classes), build and run.. when we need to add/modify the existing interceptions.
But this is the most prevalent and widely accepted AOP pattern, even in the Java side.. So I can live with it! :-)
2. There are some more implementations which use C# attributes to define custom attributes specific to the AOP engine. Then the classes that need to be intercepted will be decorated with these custom attributes. (And will necessarily become Context Bound Objects). So the AOP engine's custom attribute implementation can take over the specifics of interception for these context bound objects at runtime. Now this pattern is neither truly build time or runtime as it is both! :-)
But IMHO, this does not reflect the true/complete spirit of aspect oriented software development practices as we still need to identify/mark the classes that need to be intercepted, at coding time! Hence if we need to another class to be intercepted or drop one that is decorated.. you guessed it, we need to change the code.. compile.. run.. the whole nine yards.
(Will add examples of frameworks that do this and the ways they do it.. later!)
3. Now I have not seen any implementations on the C# side along these lines but this pattern of runtime weaving will be able to intercept the classes that need to be weaved, at runtime without any need for byte code manipulation at build time. Of course this would need a way to either override the classloader and/or be able to generate proxies/stand-ins for classes that need to be instrumented with necessary interception code in them and push the execution through these generated objects, at runtime! One the .NET side, this would mean extensive use of Reflection.Emit and proxy classes concepts (and some other innovative ways of handing some subtleties)!
AspectWerkz on the Java side has been a pioneer in this area of runtime weaving and "on the fly" compilation of join points.
This pattern with a little bit of necessary support at build time coupled with declarative aspect definitions would constitute my best choice for AOP. But again, that would have performance implications as no matter how much we optimize, runtime code weaving will be at least a tad bit costlier than build time weaving!
(Will add details about how AspectWerkz does this.. and any potential implementations on the C# side that are trying to embrace this.. later!)
So there it is! A short story about AOP progress and primer on the .NET side!
Any thoughts?
posted by Kiran at
8:09 AM
|
1 comments
