C# and Aspect Oriented Programming

One common question I've heard recently is “Are there any plans to add AOP support to C#?”

We don't currently have any plans to add AOP into the language.

My current thinking - and I'm not speaking for the whole design team now, though I think my position is at least somewhat representative - is that the scenarios that are mentioned around AOP don't justify the inclusion of new language features. One of my concerns is that AOP adds a whole new level of complexity to reading code, in that the code that is executed in a method isn't all in the method. The scenarios I've seen listed are around logging and monitoring.

So, I think it's fair to say that we're in a “wait and see” attitude on this one. If there are compelling scenarios in this area, I'd like to know about them.

Comments

• Anonymous
  June 29, 2004
  One scenario I can think about right away is transactions (one of the most boasted examples by Marc Fleury from JBoss)
  
  

• Anonymous
  June 29, 2004
  The comment has been removed

• Anonymous
  June 29, 2004
  Josh Rusk: you could use attributes and derive your "loggable" objects from ContextBound object, create a sink and intercept method calls, searching for the LoggingAttribute.
  
  Thats the beauty of ContextBoundObject
  
  One thing to EricGu: I wish ContextBoundObject itself had virtual methods that could be overriden for simpler interception, instead of having to create a ContextBoundAttribute but I'm sure there's a good reason

• Anonymous
  June 29, 2004
  The comment has been removed

• Anonymous
  June 29, 2004
  AOP is certainly a very useful concept that should be supported by further MS products.
  
  I think that it should be supported at IDE level and not at langage level. By IDE level, I mean that a VS project could accept some kind of 'AspectJ alike' syntax. With this syntax, developers could provide some rules (CLS relative and not C# or VB.NET relative) to weave code.
  
  These rules would allow the compiler to weave IL instructions. A 'must have' functionality would be that the IDE could display and debug the weaved code in sources (maybe with a special background color). That's why I think it should be an IDE feature. Without this kind of facilities, it is tough to anticipate AOP effects.
  
  

• Anonymous
  June 29, 2004
  Thanks Eric (Newton). I'll have to find some time to try that approach, it looks interesting.

• Anonymous
  June 30, 2004
  The comment has been removed

• Anonymous
  June 30, 2004
  "One of my concerns is that AOP adds a whole new level of complexity to reading code, in that the code that is executed in a method isn't all in the method."
  
  Partial Classes do the same for classes. Without the IDE you can get totally lost.
  
  If you decide to add AOP, you can always cover for it with a good IDE.

• Anonymous
  June 30, 2004
  Using the capabilities endowed by deriving from ContextBoundObject is indeed a way to implement AOP like functionality. However my issues with this solution are two fold:
  
  1) I don't always want, or in deed am able to inherit from ContextBoundObject.
  
  2) The overhead incurred during construction and method invocation are both significant i.e. you wouldn't want all your calls to incur this penalty.
  
  With regards to the applications of AOP I think that, in addition to the areas mentioned above (logging etc.), persistence and design by contract are both good candidates for making use of this technique.
  
  On the subject of the increase in complexity due to the introduction of aspects, I think that with appropriate tool support this shouldn’t be too much of an issue.
  
  One thing I think that could be a good half way house is the use of attributes to identify methods to be intercepted (as mentioned above).
  
  This isn’t true AOP as the code itself has to be decorated to implement the functionality (Aspects should really be completely orthogonal to the rest of the code), but it would provide a partial answer. Especially to my two pet interests :-)
  
  
  

• Anonymous
  June 30, 2004
  I also meant to say that I liked the idea of being able to attach event listners to methods as suggested by Thomas Eyde.

• Anonymous
  June 30, 2004
  
  Ja, I hope I made that clear.
  
  My notion of System.Runtime.Intervention is a halfway house.
  
  Deriving from ContextBoundObject is the dead weight as Tim Munroe said, why should we?.
  
  Like Tim, I have a pet project.
  My pet project http://agileopensource.net is a form of it (but where currently I am also compiling the classes which substitute compiled Types).
  Its an experiment, to see how much work is involved, what it needs and how it should work.
  
  IF only:
  By not requiring the ContextBoundObject, I am free to continue deriving from my own model.
  And the compiler only throws the switch for runtime intervention when the attribute is found, limiting the penalty.
  
  
  
  
  

• Anonymous
  June 30, 2004
  
  I just wanted to add, that the discussion from my post that mentioned the Accessors on objects is in a similar vein.
  
  http://blogs.msdn.com/ericgu/archive/2004/02/11/71533.aspx
  

• Anonymous
  June 30, 2004
  Thomas said: "If functions were first class objects, we could add listeners to them"
  
  See this series of blog posts for one way to make this happen. It's not exactly lightweight, but I hope it's interesting:
  
  http://blogs.msdn.com/jaybaz_ms/archive/2004/06/25/165931.aspx

• Anonymous
  June 30, 2004
  i would like to see some compiler-executed code too, i guess like C macros? ug... i know that'll reintroduce a whole lot of wierdness to compiled code
  
  theres gotta be a satisfactory compromise, short of "C# w/AOP language elements"

• Anonymous
  July 01, 2004
  Hi,
  Here is my implementation of the AOP.NET
  
  http://www.codeproject.com/dotnet/ContextBoundModel.asp
  
  http://www.contextboundmodel.net/
  
  It's free and open source :)

• Anonymous
  July 12, 2004
  Forgive my ignorance, but I though attributes provided AOP?

• Anonymous
  July 14, 2004
  For the most part, it seems like AOP is beneficial for implementing "runtime environment" services (logging, monitoring, transactions, etc.). But I have an example situation which could benefit from something similar.
  
  Quick Point: I've examined using ContextBoundObjects, but I'm bothered by the need to inherit from this class. It would have been much better if this had been an interface rather than a class. The standard library could have provided a simple implementation that could either have been extended or delegated to in cases where you need to inherit from a separate class. In the end to get around this, objects will have to implement their context-bound portion as an per-instance singleton inner-class that extends from ContextBoundObject and is delegated to as needed. That's ugly.
  
  Anyhow, my example...
  
  I have a simple production system that performs operations on data items based on their "state" and "type". For each (state,type) combination there is a different handler method that is supposed to perform the appropriate logic on an item. So (in "shorthand")...
  
  struct Item {
  string state;
  string itemType;
  }
  
  interface ItemHandler {
  void handleItem(Item item);
  }
  
  class ProductionSystemStateMachine {
  
  void addState(string itemType, string state, ItemHandler handler) {
  /* .... /
  }
  
  ItemHandler getNextItemHandler(Item item) {
  / .... */
  }
  }
  
  class ProductionSystem {
  ProductionSystemStateMachine sm;
  
  public static void processItem(Item item) {
  ItemHandler handler = null
  while((handler = sm.getNextItemHandler(item)) != null) {
  
  handler.handleItem(item);
  }
  }
  }
  
  Obviously, very shorthand, but you get the idea. Anyhow, I use this production system in a number of different places in my system to provide for rule-based logic. I have a particular case in which a number of the entries need to exhibit the same type of error handler, as in:
  
  MyItemHandlerA : ItemHandler {
  void handleItem(Item item) {
  try {
  doSomething();
  }
  catch(Exception e) {
  performErrorHandling();
  }
  }
  }
  
  Obviously, this can be handled lots of different ways (a shared delegate method, a base class that provides the standard behaviour in a closed method that calls a virtual method implemented by the children). But it'd be pretty clean if I could just say something like this:
  
  class MyItemHandlerA : ItemHandler {
  [UseStandardErrorHandler]
  public void handleItem(Item item) {
  doSomething();
  }
  }
  
  An interception-based approach would be an interesting way to provide for shared-code on a method-by-method basis. It is an improvement over the base-class approach in that it doesn't affect the inheritance model (ContextBoundObjects being a bad example).
  
  Of course, the argument about "the code that is executed in a method isn't all in the method" applies to both the base-class an interception models. I don't see how one is better or worse than the other from a readability standpoint as both would be labeled.
  
  

• Anonymous
  December 27, 2004
  [http://itpeixun.51.net/][http://aissl.51.net/][http://kukuxz003.freewebpage.org/][http://kukuxz001.51.net/][http://kukuxz003.51.net/][http://kukuxz005.51.net/][http://kukuxz002.51.net/][http://kukuxz004.freewebpage.org/][http://kukuxz007.51.net/][http://kukuxz001.freewebpage.org/][http://kukuxz006.51.net/][http://kukuxz002.freewebpage.org/][http://kukuxz004.51.net/][http://kukuxz008.51.net/][http://kukuxz009.51.net/][http://kukuxz005.freewebpage.org/][http://kukuxz006.freewebpage.org/][http://kukuxz007.freewebpage.org/][http://kukuxz009.freewebpage.org/]

• Anonymous
  June 02, 2009
  PingBack from http://woodtvstand.info/story.php?id=54874

• Anonymous
  June 02, 2009
  PingBack from http://woodtvstand.info/story.php?id=46921