What Is AOP?One important part of every well designed software application is its “Crosscutting concerns” something that we may call non-functional requirement. These functionalities are needed across many different layers, modules, classes within the application. Some examples are:
- Error Handling
These concerns often cannot be cleanly decomposed from the rest of the system or core concerns in both the design and implementation, and can result in either code duplication, coupling between systems, or both.
Aspect-Oriented Programming (AOP) helps to separate crosscutting concerns from the core concerns, by putting them into a separate module so we can plug that module into the core whenever needed without cluttering the code.
Why It Is Good For Your/Application Health?So why AOP is good for your health?! The short answer is: It helps you write less code and makes your life easier! So you can have more free time to spend on whatever you want e.g. going to the gym or something useful for your health or life!
Here is the longer and more technical answer:
- The business logic source code is much easier to read and understand.
- Reusable code means shorter development times and easier troubleshooting.
- Developers can better focus on implementing the main business logic or core concerns.
- Less-experienced developers won't have to learn to tackle these crosscutting concerns throughout their code.
- The crosscutting code can be replaced or upgraded easier.
- Many AOP tools and frameworks can be configured simply via configuration files without recompiling and redeploying the application which means easier maintenance.
- Separation of concerns means better unit testing and higher quality software.
As a developer, if you still believe that writing code having above qualities and possibilities makes your life easier (and healthier!), then continue reading to find out how to do AOP in .NET.
How to do AOP?A common approach to implementing behaviours to address crosscutting concerns in your application is to use the decorator/proxy patterns. But, AOP is not just a decorator! If you have a small application with a few classes, then decorator/proxy combined with dependency injection does the job for you. But, for a bigger and more complicated application, it is recommended to use an AOP framework. For more information see this: aop vs decorator.
There are several AOP implementations in .NET Framework with different capabilities and pros and cons and reviewing all of them is beyond the scope of this post. So, I will introduce only two of them which I have used.
PostsharpPostsharp is by SharpCrafters and it claims to be the most comprehensive aspect-oriented software available for .NET. It is not free or open source and its free version is limited.
PostSharp uses .NET attributes and does its work at build time after the compiler has generated the IL from your code to produce the final result using MSIL rewriting techniques.
The good thing about Postsharp is it is only a compile time thing and there won’t be performance penalty at runtime. The bad thing is, it is tied to your current compiler version and build configuration (i.e. 32 or 64 bits) and sometimes it slows down you to use for example the newer version of Visual Studio and you need to wait for a newer version of Postsharp or pay for an upgrade. And of course, there is a significant hit with compilation time in bigger applications.
Unity InterceptionAs said before, a common approach to implementing behaviours to address crosscutting concerns in your application is to use the decorator pattern. Instead of wiring the decorators up manually, you could use the Unity container to do it for you.
Unity is one of the Enterprise Library application blocks. Unity is essentially a DI container with additional support for an interception mechanism through which you can make your classes a bit more aspect-oriented.
Unity uses the Interception design pattern to dynamically create a proxy object that it inserts between the client and the target object.
The good thing about Unity Interception is that it could be configured through configuration files using matching rules, call handlers and interceptors and in comparison to Postsharp, you don’t need to add attributes to your methods or classes and of course it is from Microsoft and it is free as part of the Enterprise Library. The bad thing could be its runtime nature that can have a small performance cost.