Aspect Oriented Programming – your good friend

Team_without_starRecently I have been working on quite a big website. From the very beginning I knew I would need data caching layer or something that will smartly do it. The simplest solution is just to check if something is in cache in my method code and take it from there. Well, but what if I have 100 methods? Should I call the same logic in all of them? This is only one method call, but still 100 times, makes me feel “this is not the smartest way to do it”. Fortunately I have found out a new approach to make my caching very robust and smart. It is called Aspect Oriented Programming. By using it I have reduced the amount of my code significantly.

Object Oriented Programming is like defining players in the field

Programming is an art of dividing your functionalities into objects – I call them players. They all are playing in one team to meet the goal of the program. The main issue is when all your players have to pass the ball to one specific team member to play well (lets call this player – a star). What happens when star is sick? (or in code jargon – it is reimplemented, and it’s is causing some bugs). Your team is not able to play well anymore because the whole glory and pressure is on the star’s shoulders. Even if you have divided the responsibilities well and each of the players knows their role, your team setup is very weak.

Team_with_star

Make your star to step back

Aspect Oriented Framework allows you to solve such problems in your team (code). The way it works is very magic. Aspect Oriented Framework allows your star player to be in between of each of your players but they do not see him. They are playing like he is not there, but he helps and controls the ball. So your star is no longer a player in the field but he watches each ball passage – like a coach.

Team_without_star

Back to code – where to put logic that is shared between a few objects?

Let’s assume you want to implement logging in your application. It means that the logic responsible for putting new information into log will be executed in several places in your application. This can lead to high coupling of your objects with the logging module because in almost each method you will launch a logging method.

With AOP Framework you can capture method call before it is executed

Purely, AOP Framework allows you to capture your code before it executes the next method and decides what to do now. Your star player (your aspect) decides whether the ball is correctly passed to the other team member. Star player can even change the direction of the ball to make it reach the correct aim.

Your first level code is now not poluted with second level features

Using AOP Frameworks you can focus on your business logic and aspects like caching, authorization, logging, tracing and others are not spread through whole application. They are implemented in one place capturing almost method call and let it go further after doing their job.

Be a good coder and find your star player before he makes your team stop playing well

Looking at your code like on a team with players allows you to personalize your modules. Make them more similar to humans. If you see that one of your players is too often used in all around, maybe he should be taken out from the team and become a coach.

In my next post I will write about PostSharp AOP Framework, which made me very happy recently because I have implemented caching aspect in a very neat and clean way.

Aspire Blog Team

Aspire Systems is a global technology services firm serving as a trusted technology partner for our customers. We work with some of the world's most innovative enterprises and independent software vendors, helping them leverage technology and outsourcing in our specific areas of expertise. Our services include Product Engineering, Enterprise Solutions, Independent Testing Services and IT Infrastructure Support services. Our core philosophy of "Attention. Always." communicates our belief in lavishing care and attention on our customers and employees.

15 comments

  1. Typically I have some kind of securityaspect around a servicemethod.

    Let's assume that I want to test first my method with a user without permission and expect a SecurityException and then I want to test the method with a valid user and therefor the updated account should have been saved in the repository.

    Using PostSharp, which injects some code OnMethodEntry (which would check the Permissions) needs some kind of global state. This could be a DI container where I resolve some SecurityProvider or some kind of static variable where I can verify my permissions.

    If I want to write this test, I need to set the global state in the TestSetup and then remove it in the TestTeardown. For. ex. setting a user without rights and in the teardown setting it back. If you have advanced scenarios with many aspects (maybe external system aspects, transaction scope, Logging aspects, tracing and caching aspects) this TestSetup/TestTeardown of global state can become very cumbersome.

    Because I really like the ideas of AOP I switched from PostSharp to NAdvisor http://github.com/chrido/NAdvisor

    At first I thought that switching to runtime aspects would impact my performance really hard, but after some tracing i found out that resolving dependencies OnMethodEntry through a DI takes way longer than using that kind of Runtime Proxy AOP stuff.

  2. Typically I have some kind of securityaspect around a servicemethod.

    Let's assume that I want to test first my method with a user without permission and expect a SecurityException and then I want to test the method with a valid user and therefor the updated account should have been saved in the repository.

    Using PostSharp, which injects some code OnMethodEntry (which would check the Permissions) needs some kind of global state. This could be a DI container where I resolve some SecurityProvider or some kind of static variable where I can verify my permissions.

    If I want to write this test, I need to set the global state in the TestSetup and then remove it in the TestTeardown. For. ex. setting a user without rights and in the teardown setting it back. If you have advanced scenarios with many aspects (maybe external system aspects, transaction scope, Logging aspects, tracing and caching aspects) this TestSetup/TestTeardown of global state can become very cumbersome.

    Because I really like the ideas of AOP I switched from PostSharp to NAdvisor http://github.com/chrido/NAdvisor

    At first I thought that switching to runtime aspects would impact my performance really hard, but after some tracing i found out that resolving dependencies OnMethodEntry through a DI takes way longer than using that kind of Runtime Proxy AOP stuff.

  3. How AOP effect the performance? How can I create a bench mark that using AOP will not effect the perfromance? It is a great technique to follow.
    For me AOP is not for every developer and it is not only logging and transaction. It is beyond that.

  4. How AOP effect the performance?
    => with postsharp it is the same as you write the code, because it is weaved into the IL. Runtime Aspects like NAdivsor generate a proxy during runtime, that's lots of additional work during runtime, especially on the first call.
    My only performance penalty is typing code in a TDD manner, and since I use sql server and access legacy systems in the code the performance bottlenecks are definitly not runtime aspects.

  5. Hi Tanzeem,
    thank you for your positive remark. In next post I plan to write about postharp implementation of AOP with IoC (Inversion of Control).

    Regards
    Maciej Gren

  6. Hi Garry,

    It is really a big coincidence because I had the same issue with PostSharp and I managed to solve it without passing static variable! The layer that is using PostSharp implements special interface, and postsharp attribute check if the execution object implements it. If yes, it takes a container instance from this layer and use it for their purposes. This way, you can mock this object and test PostSharp! Really great solution. I will show it in my next post.

  7. Hi Garry,

    thank you for this reply because I was also considering this as an issue when using AOP. Fortunately, PostSharp is not influencing it and with my idea how to test it – you can quit from passing static variables into postsharp attributes. Everything will be in next post I will write this weekend!

  8. Well , the view of the passage is totally correct ,your details is really reasonable and you guy give us valuable informative post, I totally agree the standpoint of upstairs. I often surfing on this forum when I m free and I find there are so much good information we can learn in this forum! http://less-accurate.com/

Comments are closed.