Living .NET...

Musings on .NET, and the like - Manoj G [MVP, Connected Systems Developer]

Contexts & Interception revisited

I have always been awed by the concept of Interception and Aspect Oriented Programming (AOP), especially after having seen and used COM+ Services. In very, very simple terms, AOP is about taking concerns or common aspects in the code (like Concurrency, Instrumentation, Security, etc), factoring them out, and weave them into the application in ways which do not create undue coupling. Interception is just a way of realizing AOP.

The very fact that .NET provides an extensible framework for implementing your own interceptors is an exciting prospect. I would have loved to explain the whole framework myself, which mind you, is undocumented. But then, I came across some great resources, which I'll just go ahead and mention instead:

Also, make sure you give these books a good reading:

  1. Essential .NET Volume 1, Don Box (Chapter 7)
  2. Advanced .NET Remoting – Ingo Rammer (Chapters 7, 11)

Dabbling with the framework that allows you to pre and post process method calls can lead to interesting thought processes and implementations. Quite a while back, I found this great article - Declarative Transactions using ADO.NET and without Enterprise Services which showed how declarative (automatic) transactions could be envisaged around ADO.NET transactions. But the problem with the code sample was that it actually did not enlist SQL commands under a single transaction. What was really required was a context-sensitive SqlHelper class. This is were I thought I could get my hands dirty with ContextBoundObject and the like. I took the basic idea from the article forward and wrote a simpler version of the context attribute, sink and property classes. What I do here is store a SQLTransaction object as a context property and have the sink do the opening/closing of the connection, calls BeginTransaction & Commit/Rollback. Of course, the implementation does not bear the complete semantics of COM+ DTC based transactions, and hence can be viewed from the academic perspective.

I must say that code is shabby, does not have inline documentation and may require some sprucing up. Moreover, I have only made the ExecuteNonQuery method context sensitive (it is called ContextExecuteNonQuery). The remaining methods would simply need to follow suite. The entire code can be downloaded here. I apologize for not giving a comprehensive explanation, but I shall do it later sometime.

It is really interesting to know where & how aspects can be applied in real-world problems. One place that immediately occurs to me, is Logging and Instrumentation. Juval Lowy, author of the most excellent book - Programming .NET Components presents an excellent sample which can be download here. For other areas where interception can be of value, it is worth-while to look at COM+ services itself. Automatic Transactions, Security (Authentication and Authorization), Synchronization to mention a few.

Posted: Fri, Feb 18 2005 15:23 by Manoj G | with 3 comment(s)
Filed under:

Comments

Manoj G said:

Have you had any experience with .NET 2.0 systems.transactions namespace?
# March 7, 2005 8:19 PM

Geoff Tewksbury said:

I just recently started playing without Message Sinks and interception. I am impressed with how much control you have. However, I have run across a situation I need some help with. I understand that interception works within a particular 'Context'. What I want to be able to do is intercept private methods on an object. However, since these methods are called from within a 'Context' of the object, I can only intercept the public method that calls into the private methods, but not the private methods themselves. Is there a way to do this? Can I somehow create new 'Contexts' for the object and intercept the private method calls that way?
# May 11, 2006 11:28 AM

Albert said:

Is it possible to get a reference to the instance  where the method is being called?

# November 14, 2006 10:30 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)