Here's the last post in my series of AOP terminology posts.

This week's term is "weaving".

Weaving is a general term to describe how an AOP tool combines an aspect with the rest of your code.

There are two main methods of weaving:

• Post-compiliation - modifying the code after the program already been compiled
• Runtime - Modifying/replacing the code while the program is running

Castle DynamicProxy uses runtime weaving. You can think of it as just like using the decorator pattern, except instead of coding each decorator by hand, Castle DynamicProxy will create those classes for you at runtime, by combining the IInterceptor implementation (that you've created) with the object that you want to intercept.

PostSharp is a post-compiler tool. It will take the aspect class that you've defined and actually modify your compiled program to weave it in to the methods/properties/etc you want it to intercept. I think a good way to visualize this is by using a decompiler to see what the code looks like before and after PostSharp has modified it.

Here's a very basic console app with a single aspect applied to a single method.

Here's what it looks like after compiling with PostSharp turned off and then decompiling (I used ILSpy as the decompiling tool this time):

Here's what it looks like after compiling with PostSharp turned on and then decompiling:

Don't panic, it's not as complicated as it looks: don't let the weird naming throw you off. Notice line 23: that's the only line that I wrote inside of the DoStuff method. The rest all comes from the aspect. The try/catch/finally structure was all put in to place by PostSharp. The first line of the method now calls the OnEntry method that I defined in the aspect. The OnSuccess method is the last thing called inside the Try. The OnException is called inside of the Catch. And OnExit is called inside of the Finally. (Note: they all get null arguments because I don't actually do anything of value inside the aspect, otherwise you'd also see some code to create the argument objects to pass in).

You can see that even though your source code is separated out into two classes, PostSharp does the work of weaving the cross-cutting concerns into the other method.

Continued my series of posts designed to cut through the sometimes obtuse terminology around AOP, this week I'll be defining "cross cutting concerns". Well, it's the title of the blog, so I guess I should explain it at some point, eh?

A cross-cutting concern is perhaps the "softest" of the terms, because it's more of an architectural concept than a technical one.

Basically, a cross-cutting concern is some piece of functionality that may not neatly fit in to normal object-oriented architecture, and most likely doesn't add business value or satisfy a requirement on its own (aka non-functional requirements). Logging is the most common example of a cross-cutting concern, because you might use logging in the UI layer, in the business logic, in the persistence layer, etc. Even in an individual layer, logging could be used across all classes/services, cutting through and crossing all the normal boundaries.

Other examples of cross-cutting concerns, which should come as no surprise if you're a regular reader: transactions, exception handling, INotifyPropertyChanged, authorization, caching, multi-threaded/asynchronous programming, auditing (very similar to logging). What else?

I continue to try and cut through some of the confusion around AOP by providing simple definitions and examples of often obtuse terminology (see also: other terminology posts).

"Aspect" seems like the core term in "aspect oriented programming" doesn't it? An aspect is simply a way to indicate to an AOP tool: what and where. The "what" is the advice, and the "where" are join points.

Let's review the terms covered so far by looking at a very trivial example of AOP:

In that example:

• The join point is "OnEntry", i.e. before a method is executed
• The advice is the body of the OnEntry method (Logger.Write(...))
• The aspect is the MyAspectAttribute class itself
• The pointcut is a combination of the applied [MyAspect] attribute along with the join point
• i.e. the complete pointcut is "before the MyMethod method of MyClass is executed"
• in this illustration, it's a very specific pointcut, but useful real-world pointcuts would be broader
• The cross-cutting concern is logging (haven't gotten to that term yet; what's the rush, it's only the name of the site!)
• The weaving is performed by the PostSharp post-compiler (also haven't gotten to that term yet)

Looks like two more terminology posts to go. If there's a term that I'm missing or glossing over, let me know, and I'll write a post on it.

I continue to try and cut through some of the confusion around AOP by providing simple definitions and examples of often obtuse terminology (see also: other terminology posts).

Today's term: advice.

An advice is simply the code that could be executed at a pointcut. For instance, if you want to do some logging, then your advice is the code that performs the logging. If you are wrapping methods inside of a transaction, then your advice is whatever implementation of begin/commit/rollback you are using. And so on...

Here's a quick example of a tracing aspect I borrowed from the PostSharp site:

There's two advices in that aspect:

• One to write "Entering" and the method name to the trace, using Trace.TraceInformation(...)
• One to write "Exiting" and the method name to the trace, using Trace.TraceInformation(...)

Those are both very trivial advices, of course. A more complex advice could reference services, perform logic, use a lot more context information than just method name, etc.

So now that you know what a join point, a pointcut, and an advice is, you have all the puzzle pieces. The final step is to put them all together. And guess what it's called when you put them all together? (spoiler alert: it's the "A" in "AOP")

I'm trying to cut through some of the confusion around AOP by providing simple definitions and examples of often obtuse terminology (see also: other terminology posts).

Today's term: pointcut.

A pointcut is a simply a set (or an expression that returns a set) of join points. If a join point is a single line between two boxes on a flowchart, then a pointcut would be a description of a set of those lines.

For instance, if you wanted to put some logging after every time a method in a given class was called, you'd first get a pointcut of all the join points that occur after each method. If there are 5 methods in your class, you have 5 join points that make up the specified pointcut.

So if your aspect defines "OnExit", and you apply that aspect to a class "CustomerRepository", then your pointcut is "whenever a method in CustomerRepository exits". You could narrow that to a single method, or expand it to an entire namespace.

As an exercise, let's examine this snippet of code:

obj1.Method1();      // obj1 is of type Class1
obj1.Method2();
obj2.MethodA();      // obj2 is of type Class2

And now a flow chart of that, identifying exit join points:

So which of those join points would be included in a pointcut of "exiting a method of Class1"? Answer: