AOP vs MVC FilterAttributes vs Interceptors [closed]

Question

1. ASP.NET MVC proposes that use or extend built-in Authorization, Action, Result, Exception filters.
2. 3th party .Net IoC containers (Unity, Ninject, Autofac) propose Interceptors
3. 3th party AOP tools (Postsharp) propose their attributes.

Now, I'm messed up. May be I mix all of them. I would like to build robust code and stable methodology, what should I use?

Answer 1

It all starts with good application design. When the design of your application is correct, there will be a lot less reason for you to interact with those AOP like features that your UI framework exposes (this holds for WCF as well).

When you hide all business logic behind a generic interface for instance, and pass command messages to it (as shown in this article), your Controllers will become thin wrappers that often do not much more than execute such business command. In that case you will be able to implement authorization and exception filtering by wrapping those business operations, leaving the UI code clean and free from attributes. Wrapping those cross-cutting concerns around business operations can be done with both interception or plain old decorators. This gives you much more flexibility and keeps your design SOLID (which has a lot of less obvious long term benefits).

Although code weaving tools as PostSharp have its use, you should be careful with them. They inject code into your assembly using a post-compile process. This makes it very painful to unit test those classes without hitting those aspects. You can't easily test those classes in isolation (which is a precondition for unit testing). Making your aspects dependent on some static variable, complicates both aspects and unit tests. Static variables make it hard to run unit tests in parallel and the use of global constants will require tests to tear down the changed global setting correctly to prevent other tests from being influenced.

Although code weaving tools result in performance that is often greater than interception, there is no performance gain compared to the use of decorators.

Answer 2

You cited three technologies that all intend to do the same: add functionalities to an existing codebase without modifying it.

ASP.NET MVC and DI both put limitations on where you can have aspects (named filters or interceptors) because the technology is only able to add the behaviors at some locations, given they cannot edit your code. Only compiler-based technologies such as PostSharp have the ability to add aspects everywhere. However, all three are implementations of AOP concepts.

Aspects have proven benefits over conventional object-oriented programming in many use cases. It is not true that every single problem can be solved by conventional OOP with better design at the same cost. It is correct, however, that AOP is not mainstream, and that there are costs and risks associated to using a non-mainstream technology (AOP was born in the 90s and OOP in the 60s). As with any innovation, different actors have different sensibility between risks and benefits, so may become early or late adopters.

AOP is not an obstacle to unit testing, but there is little shared experience on the topic. Generally, aspects must be tested as separate units of code. There are essential and non-essential aspects. Typically, business code must be tested together with essential aspects, but non-essential aspects must be disabled. You can disable aspects either statically at build time (just exclude some aspect from the build configuration), or at run time (make the aspect dependent on some static variable that you set to false during testing).