假设应用程序的业务规则的关键部分依赖于给定的行为，但明确地编码此行为会使代码混乱，您是否依赖于将其封装在PostSharp（或任何其他方面框架）的方面物）？这是一个“安全”和“明智”的选择，还是总是更好地明确编码行为，无论它如何混乱代码？这种解决方案的可维护性如何？
答案 0 :(得分：2)
不建议将业务规则或业务逻辑放在各个方面。它违背了AOP的目的。业务规则/逻辑不是交叉问题。如果您将业务逻辑的一部分视为混乱，那么您应该使用通用的OOP实践来抽象它或将其提取到它自己的方法中。
当然，您可以将其转变为一个方面，但目标是什么？为了减少混乱？这对我来说是不可接受的。使用方面来消除与业务逻辑无关的混乱，以便明确业务逻辑。如果您的业务逻辑混乱，那么您需要重构。
PostSharp与其他AOP框架：如果最终将“关键代码”放入某个方面，那么PostSharp将是获得最佳性能的最佳框架。像IoC这样的运行时框架包含动态拦截不会像静态编译的代码那样执行。此外，PostSharp有很多优化，它基于您编写的代码执行，没有其他框架可以匹配。