主流.Net AOP Framework的功能定位分析

今天把Net AOP Frameworks Research Report v1.1一文中列出的.Net下的AOP实现方案的源码都过了一遍，每看一个方案的自我介绍，首先印入眼帘的往往就是其功能定位，从其自我介绍和提供的文档、范例等，自然就可以对其各自的功能定位下一个判断。

 

1. Aspect#

 

在所有的方案中，不谈技术能力的高低，只从其定位和文档质量来说，Aspect#给我的感觉是定位最明确，文档质量也最高。

 

首先，它的定位非常明确，也因此他能够被castle项目收录为子项目。实际上，Aspect#就是castle.dynamicproxy的扩展，而castle.dynamicproxy得本质就是通过reflection,emit,delegate，在运行时动态的为非sealed类的virtual方法生成proxy类。Aspect#则是在此基础上定义了一套configuration language，并以此为基础，方便用户使用dynamicproxy来minin和intercept。而Aspect#的限制也就是dynamicproxy天然的限制，因为要继承原来的类，只有"非sealed类的virtual方法"才能被intercept，这是不可逾越的限制。 aop.net原来的实现，恐怕也是相同的思路。（还有一点值得一提的，castle.dynamicproxy的官方首页有博客源zhengyulu兄和iaxes兄在博客园介绍castle.dynamicproxy使用的文章链接哟~~，请看：http://www.castleproject.org/index.php/DynamicProxy ）

 

当然，从技术的角度来讲，dynamicproxy一点也不先进（相较于rail这样的il级别织入来讲），不过，他也有其天然的优势：一是他的原理非常易于理解；二是易于使用；三是他基于一种假设，那就是OOD中，正确的设计往往会广泛的使用接口来降低耦合、实现各种pattern，而很大部分重要的业务代码的实现都是virtual方法，因此，虽然dynamicproxy看是限制多多，实际上还是很有必要的一种机制，用户面很广；四基于和castle项目的天然结合，用户对Aspect#的信任自然是无用质疑的。这些，都使得Aspect#必然会成功！

 

还有就是它的文档质量和示例代码非常简单易懂，他的two minute tutorial确实做到了two minute就会使用，这个也是值得其他AOP方案大大学习的地方。

 

2. AspectDNG

 

AspectDNG和Aspect#其实有一点是非常相似的，那就是他也和Aspect#那样基于另一个类库rail，rail是干什么用的呢？简单的说，rail是用来的做静态织入用的，你给我任何一个assembly，只要没有混淆，我都可以用rail在il的级别对原有的代码作修改，修改当然就包括了扩展、合并、intercept、delete等等，总之，从修改原有程序集的角度来讲，理论上是无所不能的。AspectDNG基于rail，并以在此基础上定义了一套xml格式的ILML语言，能够将原有的程序集拆散成ILML格式，方便用户的修改，修改过后，再拼装回去，就成了新的程序集，因此，AspectDNG的定位也就是非常明确的，那就是对静态程序集的修改和扩展，并为静态织入旧的程序集提供了很多方便的类库。但是记住，AspectDNG只提供静态织入，这就是它的定位。还有像Eos，和他也是类似的，只不过Eos提供了一个非常类似AspectJ的语法，但本质上，还是差不多的静态il级别织入。
 

不过，AspectDNG的文档可就比Aspect#差了点，代码中还处处是法文单词和注释，这就太不友好了，好在它的示例还算简单清晰，而rail这个类库本身的文档和示例还算是比较简明易懂的，也因此，还不算太难用。

评论

以上两者是现有的.NET下的AOP实现的佼佼者，分别是两个很明确的思路，都很好的利用了现有的第三方类库作为基础。

 

值得思索的是，其他的方案都没有这两个方案成功，不仅仅是因为其他方案提供的configuration方式没有这两个方案完善，而且因为，其他的方案，凡是希望自己实现一个地位相当于castle.dynamicproxy或rail这样的类库的，往往容易陷进某个深渊。因为，要实现一个非常好的，功能强，又稳定，又值得信任的这样的类库，真不是一件容易的事。

从底层技术的角度讲，主流的AOP Framework一般有如下三种织入方式：

1、基于dynamicproxy的运行时interception；

2、基于IL级别的静态织入；

3、基于IL级别的动态载入时织入；

 

从Configuratuion方式的角度讲，主流的AOP Framework一般有如下四种配置方式：

1、类似Aspect#的独立的自定义Configuration格式；

2、类似AspectDNG的，基于XML的Configuration格式；

3、基于Custom Attribute的Configuration格式；

4、类似AspectJ的特定语言扩展及相应的Compiler；

//文章结束