PostSharp和关键代码部分

Question

假设应用程序的业务规则的关键部分取决于给定的行为，但是明确地编写此行为会混乱您的代码，您是否依赖使用PostSharp封装它（或使用任何这方面的其他方面框架）？这是一种“安全”和“明智”的选择，还是明确地编码行为总是更好？无论它如何混淆代码？那么这种解决方案的可维护性呢？

Answer 1

不推荐在方面放置业务规则或业务逻辑。它打败了AOP的目的。业务规则/逻辑不是交叉关注的问题。如果您将业务逻辑的一部分视为混乱，那么您应该使用常见的OOP实践来抽象它或将其提取到它自己的方法中。

当然，您可以将其转变为一个方面，但目标是什么？为了减少混乱？这是我不能接受的。使用方面消除与业务逻辑无关的混乱，以便您的业务逻辑清晰。如果你的业务逻辑混乱，那么你需要重构。

PostSharp vs其他AOP框架：如果您最终将“关键代码”放入某个方面，那么PostSharp将成为获得最佳性能的最佳框架。像IoC这样的运行时框架包含动态拦截不会像静态编译的代码那样执行。另外，PostSharp有很多优化，它基于你编写的代码执行，没有其他框架可以匹配。