8
  1. ASP.NET MVC 建议使用或扩展内置的授权、操作、结果、异常过滤器。
  2. 第 3 方 .Net IoC 容器（Unity、Ninject、Autofac）提出拦截器
  3. 第 3 方 AOP 工具（Postsharp）提出了它们的属性。

现在，我搞砸了。可能是我混合了所有这些。我想构建健壮的代码和稳定的方法，我应该使用什么？

4

2 回答 2

6

这一切都始于良好的应用程序设计。当您的应用程序设计正确时，您与您的 UI 框架公开的类似 AOP 的功能进行交互的理由将大大减少（这也适用于 WCF）。

例如，当您将所有业务逻辑隐藏在通用接口之后，并向其传递命令消息（如本文所示）时，您的控制器将成为瘦包装器，通常只执行此类业务命令。在这种情况下，您将能够通过包装这些业务操作来实现授权和异常过滤，从而使 UI 代码保持干净且没有属性。可以使用拦截器或普通的旧装饰器来围绕业务运营包装这些横切关注点。这为您提供了更大的灵活性并保持您的设计可靠（这有很多不太明显的长期好处）。

尽管 PostSharp 之类的代码编织工具有其用途，但您应该小心使用它们。他们使用后编译过程将代码注入您的程序集中。这使得在不触及这些方面的情况下对这些类进行单元测试非常痛苦。您不能轻松地单独测试这些类（这是单元测试的先决条件）。使你的方面依赖于一些静态变量，这会使方面和单元测试变得复杂。静态变量使并行运行单元测试变得困难，并且使用全局常量将要求测试正确地拆除更改的全局设置，以防止其他测试受到影响。

尽管代码编织工具带来的性能通常高于拦截，但与使用装饰器相比并没有性能提升。

于 2013-02-22T03:09:02.527 回答
4

您引用了三种技术，它们都打算做同样的事情：在不修改现有代码库的情况下添加功能。

ASP.NET MVC 和 DI 都限制了您可以在哪里拥有方面（命名过滤器或拦截器），因为该技术只能在某些位置添加行为，因为它们无法编辑您的代码。只有 PostSharp 等基于编译器的技术才能在任何地方添加方面。但是，这三个都是 AOP 概念的实现。

在许多用例中，方面已证明优于传统的面向对象编程。并非每个问题都可以通过传统的 OOP 以相同的成本通过更好的设计来解决。然而，AOP 不是主流是正确的，使用非主流技术存在成本和风险（AOP 诞生于 90 年代，OOP 诞生于 60 年代）。与任何创新一样，不同的参与者对风险和收益有不同的敏感性，因此可能会成为早期或晚期采用者。

AOP 不是单元测试的障碍，但在这个主题上几乎没有共享经验。通常，方面必须作为单独的代码单元进行测试。有必要的和非必要的方面。通常，业务代码必须与基本方面一起测试，但必须禁用非基本方面。您可以在构建时静态禁用方面（只是从构建配置中排除某些方面），或者在运行时（使方面依赖于您在测试期间设置为 false 的某个静态变量）。

于 2013-02-26T09:26:16.423 回答