PostSharp 2.0 Makes Aspect-Oriented Programming Easier with IDE Support

Posted by Jonathan Allen on Oct 16, 2009

Sections

Architecture & Design,

Development

Topics

AOP ,

IDE ,

Methodologies ,

.NET ,

PostSharp ,

Programming

Share |

RELATED Research

AOP, or Aspect-Oriented Programming, allows developers to apply repetitive functionality to multiple classes without actually changing the source code for those classes. Instead, aspects or concerns are applied to classes indicated via attributes or configuration files. AOP first become widely popular with AspectJ and the Java programming language. Since then it has become available in most programming languages.

For .NET, AOP frameworks like PostSharp are implemented as a post-build process. This process decompiles the IL assembly, adds the additional functionality, and then recompiles it.To see the results, you then have to open it back up with a tool like Reflector.

PostSharp 2.0 adds two key features to makes it easier for AOP developers to understand their code. The first is an Aspect Browser. This allows developers to select an aspect and see all of the classes it applies to. This is done via a pair of tree views that resemble Visual Studio’s class viewer.

The second feature affects Visual Studios code editor. By hovering the mouse pointer over a class name, you can see all of the aspects that apply to it, even if it was applied to a base class. In addition, the tooltip that shows this information has links to take you to the definition of the aspect.

1. Back to top

   PostSharp vs Others

   by rafal buch

   I am wondering if anyone compared this to other inversion of control frameworks such as Spring, or Unity and what were the thoughts in choosing one..

   Reply

2. Back to top

   Re: PostSharp vs Others

   by David Clarke

   AOP and IOC/DI address different issues and e.g. Spring includes support for both. IOC transfers control of object instantiation from the module that requires the object to an IOC Container. Aspects typically encapsulate common behaviour for all modules, e.g. logging and authorisation.

   Reply