Aspect-Oriented Programming (AOP) and Tracing

I've been interested in Aspect-Oriented Programming (AOP) for some time now, but I hadn't actually experimented with it myself until recently.  That's not totally true, since most O/R mappers use AOP in their implementation, but I've only been a consumer of AOP in those cases.  For my own experiment, I decided to dig up an old MSDN article by Dharma Shukla, Simon Fell, and Chris Sells that used AOP for tracing.  By just decorating your class with an attribute, their code automatically adds tracing when you enter each method (with all your parameters included) and when you leave each method (with the return value included).  I modified it a little in my experiment to make explicit tracing calls much easier, and I also added a config switch to disable or enable the actual tracing output.  You could similarly modify it to output the trace to different “listeners”, or even add severity levels, but I'm just experimenting so I haven't done that yet.  This is all really cool stuff, especially since its so much easier to actually consume than other tracing methods like Log4Net, the Exception Management Application Block, or custom Trace Listeners.  By the way, that last one is an excellent article written by my good friend Jerry Dennany, who has an occassional clue here on these weblogs too.  Anyhow, my question to my few readers out there is how much does this context-bound call interception technique affect performance when you compare it to the other more traditional methods?  Also, are there any other things to worry about with these techniques, whether it be for tracing, persistence, security, or something entirely different?  And finally, what other uses have you dreamed up, or just heard about, for AOP, and what has been your experience using AOP for such things?

8 Comments

  • Compare the time it takes to call a method in your ContextBound object with the time it takes to call a standard class.



    Then you'll discover why O/R mappers that use this approach are sooo slooow.



  • ContextBound objects vs. normal objects are very slow. Unfortunately, this is the only easy way to do this type of call interception right now (there are some other ways to do it, such as re-jitting stuff on the fly...but they are a lot more difficult).

  • Also ContextBoundObjects are no longer under development by Microsoft. They will not be thrown away, but nothing new is going to be done to them (so says Don Box at a conference I can't remember...I want to say the Chris Sells XML conference), and they won't support them if something breaks.

  • Justin's remarks aren't exactly true - remoting is getting some work done in whidbey.



    Also, I believe that Microsoft will support remoting if it just 'breaks'. At the PDC, Don Box launched is initial talks with the mantra that remoting as we know it is dead, but after a relatively large uproar from the developer community, he toned down that message by several decibels. By the end of the conference, Don was suggesting that Microsoft would continue to support remoting, and that if you wished to keep using it, 'go in peace'.



  • Hi,



    Your blog contains good info. Keep it up.

  • there is a beta product out there called loom.net that helps you design fault tolerance into your system. i believe the guy doing it is also sponsored by microsoft....you can download it easy enough (i forgot the exact url but you can google for it). it has some sweet content describing how it can be done and it can give you a rough preview of how it might be implemented into .net at some point in the future (conjecture but you gotta imagine it will at some point).



    also i have been trying to get an article or two published about using attributes to assign behavior (and validation) to class properties, method parameters and such. we are using it where i am at and it is pretty cool. i can share with you some of my thoughts on it if you like.



  • EIF and most all the MS Application Blocks are just way overkill. Log4Net is almost always better, due to simplicity, than EIF.

  • Hai,

    up to this is good need more

Comments have been disabled for this content.