Compare PostSharp with other implementations of AOP

Comparing AOP-enabling technologies

A quick look at how PostSharp compared to other implementations of AOP.

	Static Weaving PostSharp	Transparent Proxy Unity	Dynamic Proxy Spring.NET, Castle
Which elements of code can you enhance?
Methods implementing an interface	Yes	Yes	Yes
Virtual public methods	Yes	Only with MarshalByRefObject	Yes
Non-virtual public methods	Yes	Only with MarshalByRefObject
Virtual protected methods	Yes		Yes
Private, protected, static methods	Yes
External methods (defined in a different assembly)	Yes
Constructors	Yes
Fields	Yes
Properties	Yes
Events	Yes
Suitability for large projects
Compile-Time Validation	Yes
Robust Aspect Composition	Yes
Visual Studio Extension	Yes
Side effects
Ability to modify aspects after build		Yes	Yes
No impact on build time		Yes	Yes
No impact on architecture	Yes
Support for Silverlight & Windows Phone 7	Yes

Dependency Injection (Dynamic Proxies)

Dependency Injection provides a level of de-coupling between objects and parameters, but requires extensive changes to your application architecture. Aspects can provide de-coupling without your application code even being aware of the associated behavior.

Advantages	Disadvantages
You may already be using a dependency-injection framework. Aspects can be configured after build. Some aspects (such as tracing or exception handling) may be provided by the framework.	Very limited aspect-oriented features. Your objects must be instantiated using the container, so it is not suitable for user interface objects (and, most of the time, for domain objects). Does not work on static, non-public, and/or non-virtual methods, neither does it work on fields, properties, or events. No, or poor, Visual Studio tooling.

Leading products: Spring.NET, Castle.
See also: LinFu, fluentAOP.

Functional programming

Pure functional languages are compact and expressive, but can’t apply aspects across a system without extraneous boilerplate code. Composing aspects together in functional languages must be done manually; aspects can’t be composed automatically, as PostSharp does in .NET.

Advantages

Disadvantages

Standard C#. You do not need another dependency in your build or runtime code. Programmers are already familiar with the technology. In some cases, it results in the same number of lines of code as with AOP.

You cannot automatically pass context from the caller to the aspect code; for instance, you can't use functional programming to implement tracing. You have to modify the code of every method to which you want to add the aspect. Real AOP can target many methods in a single piece of code and supports advanced matching and validation rules. Aspect composition is less convenient. If you have two aspects on the same methods, and later decide to invert the order of execution of aspects, you must edit every method.

Code generation

An orthogonal productivity technology, code generation can automatically create code from models and UI gestures, but cannot instrument existing source.

Advantages	Disadvantages
It is easy to generate complex source code since all the developer manipulates is C# or Visual Basic. The resulting C#/VB code can be opened in Visual Studio and debugged, like any other source code.	Unlike AOP, the input artifact of a code generator is typically an XML file, not the source code itself. The technology cannot inject new instructions into existing source code, or modify the behavior of existing source code in any way.

Leading products: T4, CodeSmith Generator.

Dynamic languages

While dynamic languages are powerful their power comes from their lack of restrictions. AOP couples the benefits of dynamic languages with a disciplined approach to software engineering.

Advantages	Disadvantages
Meta-programming for dynamic languages is easy, since these languages are designed for that purpose.	You will need to switch to a dynamic language. This is not an easy choice. Meta-programming may be too powerful a tool for you; a more disciplined approach may be appropriate. No Visual Studio tooling.

Low-Level MSIL Transformation

While transformations eliminate one or two DLL dependencies, it takes a herculean effort to master. Plus, using MSIL requires abandoning the engineering discipline provided by .NET languages.

Advantages

Disadvantages

Eliminates the runtime dependency to PostSharp.dll (note that you could achieve the same benefit by using PostSharp SDK). Very powerful. You can achieve virtually any code transformation (even an incorrect one). These frameworks are free of charge and backed by large companies.

Requires an advanced knowledge of MSIL. Note that in MSIL it's quite easy to write a prototype, but it's much harder to write a transformation that works in every condition. You will permanently reinvent the wheel. MSIL transformation libraries are generally very low-level, they don't deliver the high-level features of the PostSharp SDK. Transformations implemented this way typically do not compose well when many are applied to the same method. No Visual Studio tooling.

Leading products: Cecil, Microsoft CCI, PostSharp SDK*

*no longer officially supported

AOP with Static Weaving

Aspect-oriented programming is a branch of discipline of software engineering that was specifically developed to address the issues of cross-cutting concerns. Static weaving uses low-level MSIL transformation internally, but does not expose the complexity of MSIL to developers.

Advantages	Disadvantages
Real AOP frameworks are very powerful. They allow most patterns to be expressed as aspects. Aspect usage is verified at build time. Developers spend less time debugging. Runtime performance is better since weaving is achieved at build time. Visual Studio tooling makes Intellisense aware of aspects, and enables developers to navigate between application code and aspects.	Static weaving increases build time. Real aspect-oriented programming is new to many developers and you may have to fight resistance in your team.

Leading product: PostSharp
See also: Afterthought, AspectDNG, Aspect.NET, Compose*, Gripper-LOOM.NET, LinFu, NSurgeon, Phx.Morph/Wicca, PostCrap, SheepAOP, Snap