Aspect Oriented Programming in C#

Aspect Oriented Programming in c#

Set the tracing class access modifier to public

public class TracingAspect : IMessageSink
{
    public TracingAspect(IMessageSink next)
    {
        m_next = next;
    }

Additional:

Internal access modifier is the default access modifier for a class if none is specified and internal class is accessible only by classes within the same assembly.

Project1
    > Class1
Project2
    > Class2 (internal)

Class2 of Project2 is only accessible by classes inside Project2 assembly. Hence, Class1 cannot create an instance / inherit Class2

Aspect Oriented Programing (AOP) solutions for C# (.Net) and their features

As Adam Rackis points out, Post# is the way to go, it is as close you will get to AspectJ on the .NET platform.

Main differences is obviously that AspecJ has language support for aspects while Post# is a post compile weaver for .NET assemblies.
(thus no language integration)

However, Post# can use join points such as field access, try catch blocks, both calls and functions (that is, caller and callee)

1. No not even close, AspectJ is a language, Post# can use custom pointcuts but the most common is to use attributes to decorate methods to be pointcutted(eh..grammar?)

2. check

3. everything but language support

4. check

5. check - it is a post compile weaver

6. limited, the weaver will generate intellisense information and show what methods have been affected

If you want a .NET language that supports aspects, check out http://aspectsharpcomp.sourceforge.net/samples.htm

Regarding different approaches, there are a few:

1. Post compile weaving , this is what Post# does.
   It simply mangles the .NET assembly and injects the aspect code.

2. Real Proxy / MarshallByRefObject.
   Based on remoting infrastructure.
   Requires your classes to inherit from a base class.
   Extremely bad performance and no "self interception"

3. Dynamic Proxy.
   This is what my old library NAspect used.
   you use a factory to create a subclass of the type on which you want to apply aspects.
   The subclass will add mixin code using interfaces and override virtual methods and inject interceptor code.

4. Source code weaving.
   As the name implies, it transforms your source code before compilation.

[edit] I forgot to add this one to the list:

5. Interface proxies
   Similar to Dynamic Proxy, but instead of applying the interception code to a subclass, the interception code is added to a runtime generated interface proxy.
   That is, you get an object that implements a given interface, this object then delegates each call to any of the interface methods first to the AOP interception code and then it delegates the call to the real object.
   That is, you have two objects at play here, the proxy and the subject(your real object).

Client -> Interface Proxy -> AOP interception -> Target/Subject

This is AFAIK what Spring does.

1) and 3) are the most common.
They both have pros and cons:

Post Compilation:

Pros:

• Can point cut pretty much everything, static , sealed, private
• Objects can still be created using "new"

Cons:

• Can not apply aspects based on context, that is , if a type is affected, it will be affected for the entire application.

• Pointcutting private, static, sealed constructs may lead to confusion since it breaks fundamental OO rules.

Dynamic Proxy:

Pros:

• Contextual, one typ can have different aspects applied based on context.

• Easy to use, no configuration or build steps.

Cons:

• Limited pointcuts, only interface members and virtual members can be intercepted

• must use factory to create objects

Aspect Oriented Programming in C#

Just to get your head around it: It is the ability to hook events such as: creation of objects, setting of properties, etc, and attach general functions to them, that will be populated with relevant context.

Because C# doesn't have an inbuilt facility for this, you need a framework, like PostSharp, to do 'bytecode weaving' (i.e. just writing code to actually make the calls, directly to your classes) to simulate it.

C# and AOP - AOPAlliance (Aspect-oriented programming) how does this work

I believe this is possible because Spring.Net is emitting proxy classes at runtime which skip compile time type checks.

It essentially implements a decorator pattern wrapping the original class and dynamically generating a new method implementation. In the dynamically generated proxy method the return type can be changed when it writes the IL, and .NET allows it because it doesn't check the type at runtime. At compile time of course it's also still perfectly valid. This leads to the rather weird scenario above whereby your static type is actually different to the runtime type.

The following is true because it's checking the actual runtime type, which can in cases resolve to Boolean.

updates.GetType().Name == "Boolean"

But the following fails because it's comparing the static type of the variable to Boolean, which it's not.

updates is bool == false

I would recommend that you don't change the type within Invoke.

---

Related Topics