现在，我搞砸了。可能是我混合了所有这些。 我想构建健壮的代码和稳定的方法，我应该使用什么？
答案 0 :(得分：6)
这一切都始于良好的应用程序设计。当您的应用程序设计正确时，您将很少有理由与您的UI框架公开的那些AOP交互（这也适用于WCF）。
例如，当您隐藏通用接口背后的所有业务逻辑并将命令消息传递给它时（如this article所示），您的控制器将成为瘦包装器，通常只需执行此类业务命令。在这种情况下，您将能够通过包装这些业务操作来实现授权和异常过滤，从而使UI代码保持干净且不受属性影响。围绕业务运营解决这些跨领域问题可以通过拦截或plain old decorators完成。这为您提供了更大的灵活性，并保留了您的设计SOLID（其长期效益不太明显）。
尽管PostSharp的编码工具有其用途，但您应该小心使用它们。他们使用后编译过程将代码注入到程序集中。这使得在没有达到这些方面的情况下对这些类进行单元测试非常痛苦。您无法轻易地单独测试这些类（这是单元测试的前提条件）。使您的方面依赖于某些静态变量，使方面和单元测试复杂化。静态变量使得难以并行运行单元测试，并且使用全局常量将需要测试以正确地拆除更改的全局设置以防止其他测试受到影响。
尽管代码编织工具的性能通常高于拦截，但与使用装饰器相比，没有性能提升。
答案 1 :(得分：4)
您引用了三种都打算做同样的技术：在不修改现有代码库的情况下添加功能。
ASP.NET MVC和DI都限制 你可以拥有方面（命名过滤器或拦截器）因为该技术只能在某些位置添加行为，因为它们无法编辑你的码。只有基于编译器的技术（如PostSharp）才能在各处添加方面。但是，这三个都是AOP概念的实现。
在许多用例中，方面已证明优于传统的面向对象编程。传统的OOP可以通过更好的设计以相同的成本解决每一个问题。然而，正确的是，AOP不是主流，并且存在与使用非主流技术相关的成本和风险（AOP诞生于90年代，OOP诞生于60年代）。与任何创新一样，不同的参与者在风险和利益之间具有不同的敏感性，因此可能成为早期或晚期的采用者。
AOP不是单元测试的障碍，但在该主题上几乎没有共享经验。通常，必须将方面作为单独的代码单元进行测试。有必要和非必要的方面。通常，业务代码必须与必要方面一起进行测试，但必须禁用非必要方面。您可以在构建时静态禁用方面（只是从构建配置中排除某些方面），或者在运行时（使方面依赖于在测试期间设置为false的某个静态变量）。