PostSharp & Critical Code Parts

Question

Supposing a critical part of an application's business rules are dependent on a given behavior, but that coding this behavior explicitly will clutter your code, would you rely on encapsulating it in an aspect with PostSharp (or with any other aspect framework for that matter)? Is that a "safe" and "wise" option, or is it always better to explicitly code the behavior no matter how it will clutter the code? What about the maintainability of such a solution?

Answer 1

It is not recommend putting business rules or business logic in aspects. It defeats the purpose of AOP. Business rules/logic are not cross cutting concerns. If you consider part of your business logic as clutter then you should use common OOP practices to abstract it or extract it into it's own method(s).

You can, of course, move it into an aspect, but what would the goal be? To reduce clutter? That isn't acceptable to me. Use aspects to remove clutter not related to business logic so that your business logic is clear. If your business logic is cluttered then you need to refactor.

PostSharp vs other AOP frameworks: If you do end up putting "critical code" into an aspect, then PostSharp will be the best framework to get the best performance. Runtime frameworks like IoC contains that do dynamic interception will not perform as well as statically compiled code. Plus, PostSharp has so many optimizations that it performs based on the code you write that no other framework can match.