Next to several rumors on support for SQL and XML language elements in C# version 3, a new rumor is releasad in the blog-o-sphere.

According to Jimmy Nilsson it could well be possible that C# 3.0 comes with support for AOP Mixins... Wow!

I assume this doesn’t only cover AOP Mixins (as a way to accomplish multiple inheritance) but also the (far more usefull) AOP concept of advice.

Even though making assumptions is tricky, in al my excitement all give you an idea of what 'Advice' is anyway... :-P

In Aspect Oriented Programming (AOP) Advice is used to implement crosscutting concerns without scattering code (or without loss of a ‘single point of definition’).

In Object Orientation you suffer from scattering if there seems to a specific logic implemented in multiple places across your program, without being able to refactor it out using design patterns.

Imagine that must of the code you write looks like the following method.

public void DoWork(...)

{

    using(TxManager transactionManager = new TxManager())

    {

        transactionManager.BeginCtx();

        //do work

        transactionManager.CommitCtx();

    }

}


Every time you write a method like this, you are implementing transaction logic somewhere it doesn’t belong (business entity of some kind).

Advice solves this problem by ‘injecting’ the transaction management code around multiple methods across your program logic. A piece of advice that injects this same transaction logic into every method named DoXXX could look something like this (somewhat imaginary syntax, based on Aspect#):

[Mix(“Do*(*)”)]

public class TransactionAdivce: IAdvice

{

    public object Invoke(IMethodInvocation methodInvocation)

    {

        using(TxManager transactionManager = new TxManager())

        {

            transactionManager.BeginCtx();

            methodInvocation.Proceed();

            transactionManager.CommitCtx();

        }

    }

}

Whenever a method called DoXXX is called -instead of the actual method- the TransactionAdvice is called by the runtime. The original method invocation is passed to the Advice as a parameter and the call can be proceeded from within the advice. With this approach the transaction logic is left out of business entities (where it simply didn’t belong anyway) and defined in 1 place at compile time.

Same could be done for Caching, Parameter checking, Logging, Security checking, ...  

If you simply can’t wait till the first C# compilers are available from Microsoft, you can always get your hands dirty on Aspect# (works in combination with C# 1.0)