AOP在.NET中的现实

因为最近关注AOP的人越来越多，所以就阅读了一些关于AOP方面的文章，一篇个人认为比较好的文章是我在CSDN上看到的转载的一篇文章，转载者没有注明出处是哪里，所以我只好将转载网址贴在这里了《AOP及其Java实现机制》。如果您还没有听说过AOP或者还不怎么了解，欢迎首先阅读转载文章然后再继续这篇Blog。

由于目前我对Java的了解不是非常丰富，所以就不对Java方面的AOP作出评论了，但就.NET而言，我觉得AOP在.NET中的实现还是有一定的不理想因素的。

AOP思想

AOP的基本思想是将不同方面（Aspect）的代码分别开来写，达到逻辑清晰，可复用的目的。与OOP不同，AOP的核心是关注点（Concern），它将程序分为核心关注点（业务）与横切关注点（可能有纠结的功能，例如日志、事务等）。AOP并不与OOP冲突，OOP是AOP中实现业务的手段，我们主要用OOP来做核心关注点与横切关注点的实现，然后用AOP将这两种关注点合并产出最终程序。

AOP的实现

目前，AOP会通过织入器（Weaver）将不同方面的代码混合（织入），织入的方式多种多样，一般来说，只要是能够将两段毫不相干的代码混合在一起，那么就可以叫做织入了。不过，目前大多数产品的做法是采用反射、动态代理、元数据等方法来作为AOP的织入方法。我在下面要讲的，就是反驳大多数采用动态代理来作为AOP织入机制的产品，也就是我前面说到的AOP目前来说，至少在.NET中，还是不太理想的。

Aspect#

在.NET下也有不少的AOP框架，其中比较有名的当数Aspect#，但是我在对它进行了一定的使用测试后，发现了至少对我来说，它丝毫没有用处。它的实现机制就是大名鼎鼎的动态代理与反射。对于还不熟悉动态代理的朋友，它说白了就是“代理”模式的动态形态，可以动态的生成某个类的代理。至于代理模式，就是GoF中著名的23个设计模式之一的代理模式，还不明白的朋友赶快翻阅一下《Java与模式》吧！^_^

AOP中的代理模式

你也许会问，我到底对动态代理有什么不满呢？没有，我对动态代理没什么不满，如果使用正确的话，动态代理还是很有价值的。不过，要想作为AOP的万能织入器的其中一种，动态代理就不是那么可靠了。熟悉代理模式的朋友一定都知道代理模式是靠继承（或对“基接口”的实现）实现代理的，那么如果一个类不可以被继承呢？Bingo，这时代理模式就不成立了，也就是说，如果你用Aspect#对一个sealed类进行Mixin的话（混合以便动态增添新功能）那么它就会失败，因为无法创建动态代理。这到底是怎么回事呢？让我们来看看代理模式（在这里更准确的说应该是装饰模式）是如何做到织入新代码的：

public class A ...{
   public A() ...{}
}

public interface ILog ...{
   void Log();
}

public class ProxyForA : A, ILog ...{
   public ProxyForA() ...{}

   void ILog.Log() ...{
      //......
   }
}

A a = new ProxyForA();
ILog log = (ILog) a;
log.Log();

就像你看到的上面的代码，动态代理会动态的生成这个Proxy类，并且通过一个Wrapper来将它返回，作为一个A看待，这时看不到ProxyForA存在的你可能会认为真的很神奇，将A的行为扩展了，但当A是sealed类时利用动态代理的弊端就暴露了，因为A是不可以被继承的。这也从另一面证实了一个OO设计原则的重要性：DIP（Dependence Inversion Principle），这个原则基本上告诉我们要以抽象概念做设计，不是以具体，这样，我们就永远都有可能使用代理模式了。关于OO设计原则，我在CSDN上的Blog有一篇总结它们的文章，感兴趣的朋友可以参阅一下^_^

那么现在让我们来看看AOP中的另一个织入手段，拦截器（Interceptor）。拦截器可以根据一个或多个切入点找到要切入的代码部分然后将横切方面（日志、事务等）代码织入，这个织入手段同Mixin一样，本身没有什么问题，问题出在在Aspect#中也是通过代理来实现织入的，这样就又带来了一个新的问题，什么问题呢？虽然目前.NET下AOP框架产品对于切入点的支持不是很广泛，但这也只是迟早的事，问题还是没有的，真正的问题就出在使用代理模式上面，让我们来看看如何通过代理模式在已有的类成员中实现织入：

public class A ...{
   public virtual void Do() ...{
      //....
   }
}

public class ProxyForA : A ...{
   private IInterceptor _interceptor = new LogInterceptor();

   public ProxyForA() ...{
      _interceptor.Instance = this;
   }

   public override void Do() ...{
      bool proceed = _interceptor.Intercept();
      if (proceed) ...{
         base.Do();
      }
   }
}

使用动态代理实现切入点的织入就是以以上方式实现的，可以很清楚的看到，这只在A类中的Do方法为virtual时才可以实现，如果某个要切入的成员不是virtual，那么织入就会失败。

总结

以上所谈到的两个使用动态代理的缺陷都是很严重的，如果非要改动代码来适应动态代理的话就会破坏面向对象的设计，严重的甚至可以带来安全隐患。

正因为上述原因，我觉得Aspect#不是一个很理想的产品。个人觉得一种较好的AOP织入实现方式是代码在编译前的替换，这样可以避免所有限制与问题，但缺点是非常难实现。目前我觉得使用AOP框架倒不如自己的好设计，如果设计的得体，那么同样可以后期通过代理、装饰等模式对系统的行为进行快速方便的扩展。同时我也很期待新的技术的出现来使AOP成为现实！