架构深渊

慢慢走进程序的深渊……关注领域驱动设计、测试驱动开发、设计模式、企业应用架构模式……积累技术细节,以设计架构为宗。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

.Net阵营的AOP工具

Posted on 2009-03-22 14:29  chen eric  阅读(1798)  评论(1编辑  收藏  举报

 

.Net阵营的AOP工具
2009-03-09 00:20

今天把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;

1. Aspect#

Version: 2.1.1.0

Link: http://aspectsharp.sourceforge.net/

Status: beta

Dependency: antlr, Castle.DynamicProxy

Description:

Aspect# is an AOP (Aspect Oriented Programming) framework for the CLI (.Net and Mono). It relies on DynamicProxy and offers a built-in language to declare and configure aspects, and is compliant to AopAlliance. It became part of the Castle Project in June 2005.

Main Features:

- Custom mini configuration language, not xml.

- Mix/Intercept classes and methods through dicnamic proxy approach.

Restrictions:

- Classes to be created dynamic proxy for shouldn’t be sealed and only virtual methods can be intercepted.

- Using intercepted classes is not completely transaparent to users that users should explicit create the dynamically proxied class through the AspectEngine.

- No static weaving support.

2. AspectDNG

Version: 0.7

Status: beta

Link: http://www.dotnetguru.org/downloads/AspectDNG/???

Dependency: mono.petoolkit, rail

Description:

AspectDNG is a .NET aspect weaver, that's to say a tool that can "transplant" code into an existing assembly. This transplant is made after the standard .NET compilation, which means that both aspect and the so called "base" code (the one the transplant will be operated on) can be developped in any programming language that is compatible with .NET CLS. Another way to say that: AspectDNG works on assemblies (EXE or DLL) that may have been created out of C#, VB.NET, Eiffel.NET, Mananged C++...

Main Features:

- Xml, Xpath based configuration file format.

- IL level static Weaving.

- Custom xml based disassembled language ILML which can be used to convert assemblies to and be modified/combined and then converted to assemblies.

Restrictions:

- Static weaving only.

- Not very stable.

3. Eos

Version: 0.3.3

Link: http://www.cs.virginia.edu/~eos

Status: beta

Dependency: none

Description:

Eos is an aspect-oriented extension for C# on Microsoft® .NET Framework™. Eos aims to improve upon the current aspect-oriented language model in three dimensions. First, it generalizes aspect instantiation & advice weaving model to eliminate the need for the work-arounds that are unavoidable today when aspects are used to express certain crosscutting concerns. Second it generalizes the join point model. Third it aims to eliminate the distinction between class and aspect constructs in favor of a single conceptual building block that combines the expressive capabilities of current classes and aspects, significantly improving conceptual integrity and uniformity in language design. The language is very similar to AspectJ except for constructs which are not implemented in Eos and constructs which AspectJ does not provides.

Main Features:

- AspectJ like extended C# langauage and custom compiler.

Restrictions:

- Static weaving only.

- Not very stable.

4. Encase

Version: 0.7

Link: http://theagiledeveloper.com/category/15.aspx

Status: beta

Dependency: none

Description:

Encase is an aspect oriented programming framework for the .NET Platform written in C#. Encase is unique in that it provides aspects to be applied during runtime in managed code rather then being configuration file based that other AOP frameworks rely upon. The advantage of applying aspects in this way is that it promotes productivity to developers new and/or unfamiliar with AOP.

Restrictions:

- Encase cannot mixin multiple classes that implement a shared interface? For instance, if class A implements Ialphabet, and class B implements Ialphabet, classes A and B can not both be mixed in as an aspect.

- Encase can only provide interception and aspect weaving to virtual (overriable) methods and properties.

- Encase is unable to apply aspects to sealed (NotInheritable) classes.

- Like Aspect#, but more unstable.

5. Post#

Version: 1.0.0.0

Link: http://gael.fraiteur.net/postsharp.aspx

Status: alpha

Dependency: none

Description:

PostSharp is a free and open-source post-compiler for the .NET Framework. PostSharp is an extensible platform that makes it easy to develop and execute static program analysis and program transformation plug-ins.

Main Features:

- Developped under .Net Framework 2.0 beta

- There is a very good third pary collection library – “Xipho.Collections” for .Net 2.0 in the source code

Restrictions:

- Not say to be a really aop framework yet.

6. Loom.Net

Version: 1.5 Beta2

Link: http://www.dcl.hpi.uni-potsdam.de/research/loom/

Status: beta

Dependency: none

Description:

The LOOM .NET project aims to investigate and promote the usage of AOP in the context of the Microsoft .NET framework. We have been developing two AOP tools (so called weavers) that all implement different approaches to weaving: A runtime weaver crating weaved objects on the fly and a static weaver.

Main

- Support under .Net Framework 2.0 beta

- Include both dynamic proxy based dynamic interception and il level rail like static weaving support.

Restrictions:

- Not very stable.

7. Others

AspectC# (AspectJ like C# extended compiler)
Weave.NET (provide a load-time il level weaving implementing)
Features: