AOP有着它优良的好处, 从一个层面上去关心一个问题, .NET对此有良好的支持.如果硬生生的看MSDN不理解里面的思想是有掉入深渊的感觉的.
为了理解AOP的机制, 我们从需求开始说起,实现AOP就是能在方法执行之前插入一段代码.当然这里所说的方法包括构造函数.
微软的实现策略是将对某些方法的调用转换成消息, 再将消息转换为方法调用, 此时就在方法的调用上产生了空隙, 这个空隙就是可以进行利用的, 举例来说吧, A方法调用了B方法, 首先将A的调用B这个行为的栈帧消息化, 消息化后可以发送到任何地方(跨Domain或者跨机器都是可以的), 拿到消息后还原栈帧,可以直接调用B方法了.负责这项工作的类是System.Runtime.Remoting.Proxies.RealProxy以及封送调用的透明代理.
因为走消息化这一套是需要成本的, 我们通常情况下是不需要这么去做的, 所以在.NET设计时就要考虑从特定结构上继承的才会享有此待遇. .NET选择了 System.MarshalByRefObject对象作为基类, .NET Clr给此类的所有子类一个特权, 就是可以消息化(注意这里是可以, 而不是一定); 另外提一句, 编译器也是对此特殊优待的, 从System.MarshalByRefObject对象上继承的任何类的方法都不会被内敛(内敛了就不存在方法了, 也就不可能被消息化).
这个过程要自己生成RealProxy对象, 所以比较繁琐, 强大的.NET怎么能忍心看苦逼的程序员饱受此困扰呢,这是又有了个更优待的对象System.ContextBoundObject, 又一个特等公民产生了, ContextBoundObject能自动产生透明代理(具体可以参看object activation), 那么我们的AOP行为从那里指定呢, 这就得益于.NET的元数据编程了, 使用.NET特性. 特性必须实现System.Runtime.Remoting.Contexts.IContextAttribute即可.
这样就有了现在的.NET AOP的实现.