好在我最近比较冷静，所以虽然你的话语过激，但我还是可以接受

什么是aop，aop的面向方面到底意味着什么？

当一个类可以对外部情况无知的时候
它的被调用却发生了悄悄的变化

比如你的计算类，通过aop可以切入日志记录的功能，
而这一切和类的本身没有任何关系，类是不具备日志纪录功能的，
但通过属性来达到同样目的的话，类是先知先觉的，属性会成为它的一部分(我还是这样认为)，即类因为这个属性而具备了相关的身份(可被纪录日志)，而并不是就具备了日志纪录的功能。你依然需要另外编码去实现功能，也就是说一共要两步：1、标识身份 2、实现功能
这样的话就存在着一个“彼此可知”的关系在里面

再看java下aop的实现，一步到位地在功能实现处就定义好了要切入的类是什么，这样的话对于编程来说，类对要实现这个功能是未知的，也就是我所理解的“横向切入”的一个关键的地方

同样，如com+的transaction属性的应用，同样是在类的实现中就明确地告诉它要使用事务设置，虽然它不关心具体的实现，但它却要知道有这个实现，等于事先要给这个类一个身份标识卡(当然也可以事后给)

我没有说你的设计达不到所要实现的目的，只是说这不是真正的aop,你也用不着这么激动，同样如果我的理解错误，估计也不至于要成为“植物人”这么惨，为什么每次我意见和你不合时你总有那么多的贬义词加在我身上呢，讨论技术而已，上到人身攻击就没什么意思了，就算MVP也罢，同样如此。

另外可以告诉你，我.net没有做到任何项目，java没有写过一行代码，我仍在用vb6，浅薄一点大概也是可以理解的。

我觉得原文的焦点在于如何用.Net的Remoting来实现AOP，而用属性来表示这个类需要LOG只是一种标示方法而已，如果用其他的方式比如一个config文件而不用属性对于原先的架构没有根本性的影响，所以似乎应该大家先把精力集中到Remoting上来，关于使用属性的优劣再开文论战。

对于progame 所讲的com+的transaction例子，类的实现中就明确地告诉它要使用事务设置，同时代码里面要有事务的处理，这和设计类时就明确用属性表示要进行日志纪录不是一样的吗。

@progame:

先说技术问题：我现在理解你所说的“属性成为了类的一部分”是什么意思了。我想，那只是一种使用属性的方式而已，有些类似于为方法传入了额外的参数。实际上，为一个类或一个成员施加自定义属性并不意味着这个类必须要知晓这个属性（大部分时候属性也是应该这样去设计的）。换言之，被施加属性的类与自定义属性本身是不存在依赖关系的，更别说谁是谁的一部分了。

以我文中的例子来说，你的意思是说在Calculator类中需要感知Logging属性的存在它才能添加Logging方面的功能？那我在下一篇文章中一定会注意，保证Calculator类毫不知晓Logging属性的存在却也能够在执行时产生logging的行为——这样就证明我的观点了。：）

> 再看java下aop的实现，一步到位地在功能实现处就定义好了要切入的类是什么，这样的话对于编程来说，类对要实现这个功能是未知的，也就是我所理解的“横向切入”的一个关键的地方。

能否举例说明？Java怎么样“在功能实现处就定义要切入的类”？这样的切入在我看来才是“切入的类成为了被切入类的一部分”啊。这方面资料我看得不多，确实不太清楚。请你一定要写上几句Java代码，我很想看看Java的AOP是怎样比.NET强很多的以至于让你觉得是真正的AOP。

最后关于人身攻击的问题——无论如何，既然你提到这个问题，我首先向你道歉！不过我必须声明：首先这和MVP无关，上次与你争论技术问题的时候我还不是MVP，现在我有幸成为了MVP但我还是要和你争论技术问题，这一点不会有任何变化——只要我觉得这个问题值得争论。：）其次，我尽量就事论事，如果确有用词不当的地方，只要你提出来，我马上改正。就本篇而言，为了防止别人可能对你产生的误解，我把关于“植物人”的那半句话删去了——这样大家都不用这么紧张了。

技术观点不同的争论是常有的事情，我想两位不必太往心里去。
有争论才有进步和提高。

没有绝对的技术机制，属性的使用自从他问世以来就一直是仁者见仁，智者见智。只要解决了你想要解决的问题就有他应用的必要。

理论上的AOP的很完美的，但是如果结合目前实际来看，至少我了解到的以及我自己的这一丁点儿知识，感觉AOP还只能是一个循序渐进的过程。以后会需有更新更好的技术出现，从而使得AOP的模式相对简单的被实现。

我想我会在下一项目中尽可能的对于AOP模式有所实践，这样会有更多体会和发言权。

@microhelper:

本篇随笔就是供讨论custom attribute的，原文我想还是关注于基于.NET Remoting Infrastructure实现的AOP的话题吧。请放心发表你认为有价值的实践经验和看法——尤其欢迎熟悉Java的朋友为我们说明在Java平台上实现AOP的机制，这样的借鉴是很有意义的。

还有，要声明一下，我对属性绝对是支持的，它的强大功能使类变得“可配置”，我从不否定属性的有用性，但我只是对它使用的场合表示置疑。

另外，我对.net的喜爱同样远远超出java，但java世界已有的很多设计思想是值得借鉴的，当然，假以时日，.net必然会迎头赶上，但.net的易用性反而会稍稍减缓这个步伐，正如vb的易用性让广大的vb使用人员深受其害一样。

“不争论，大胆地试，大胆地闯，发展才是硬道理。”

@progame:

你这段代码不是Java代码，而是AspectJ的代码。它是一套为给Java语言添加AOP机制而独立设计并实现的语言（www.AspectJ.org），配合其自己的编译器以及自动代码构建引擎（如Ant），在Java程序编译阶段将aspect逻辑代码“缝合”到对应的对象方法上——正是因为他的静态编译实现机制，使得他无法在运行时动态的为对象添加或取消新的或已有的aspect实现。

同样，.NET中的语言（如C#/VB.NET等）自身也不支持AOP，但是其公共语言运行时（CLR）却提供了一些机制允许为已有的对象添加任意的aspect（其实也不是官方方法，而只是利用.NET Remoting基础架构中的扩展机制而已——毕竟.NET Remoting就是基于这个基础架构得以实现的）。

DynamicProxy的思路基本上就是microhelper关于一个RTM的思路（主要使用Reflection提供的动态方法调用——类似于COM中给予IDispatch的late binding——没错，都是要从一个既定接口实现！），但是如果它的作者能够略微了解一些.NET Remoting的原理，应该就不会有这篇文字出现了——anyway, it's a great alternative which let you know how it could be implemented (as well as my decorator-based approach). And alternatives are always good to thinking and understanding things (as Saucer quoted before.)

@progame:

Yeah I have lots of Java books in my reference library which enable me to know and apply many useful ideas when working in a .NET world. And my 15-year programming and designing experience gives me a clear view of what's good and what's not - from a practice perspective, that I would share with all of you, more than anxiously. :)

刚开始没有仔细看标题，一直以为是写的是
“动物属性依然是人类的一部分？”
然后就没有仔细看。

还是开心厉害，：）

开心这是咋整的——老眼昏花啦？唉，工作太辛苦！太辛苦呀！嘿嘿……

可能真是吧，呵呵。
我现在做的超低级工作，把数据库字段与页面上的控件一一对应，提交到数据库中，一不小心就对错:'(

@开心就好：

你够洋的啊！这绝对是一高技术活儿啊！呵呵~~：）

microhelper的RTM是调用时进行代理
而DynamicProxy是创建时就代理了

我希望不用代理，直接调用
当然在这种情况不可行时只好退而求其次选择DynamicProxy

我知道aspectj还没有纳入java语言中，但这是大势所趋
所以我希望能够看到.net在aop方面有更好的表现和更大的突破

@progame:

CLR知道谁也不喜欢显式的通过代理去调用对象的方法，可是如果想实现运行期方法拦截，不用代理又不行，所以他们很聪明的实现了所谓“透明代理”（TransparentProxy）的机制——正是我希望让大家了解的在.NET中实现AOP的机制。当然，因为Proxy模式是结构型模式，很自然的CLR还增加了对象创建（或称激活）的支持，使其透明的在运行时将TransparentProxy构建并返回给客户代码（通过new关键字或Activator类的静态方法）——而自定义属性恰恰是告知CLR这一个构造逻辑关键信息的一种途径（还好.NET很灵活，以至于我们完全可以使用自己的任何机制来创建并返回这个透明代理——当然，这样一来我们就需要使用自己的对象创建型模式喽）。

我想讨论问题到这个地步，就算俺不写下篇文章大家的思路也都基本上八九不离十了吧。：）

@Ken:

你说得很有道理：动静皆宜，归根结底技术还是为了满足软件开发的实际需求，只有了解了各种技术的优势劣势，我们才能更好的权衡利弊，最终选择最合适我们的开发平台和实现技术，把软件做好。

不好意思的说，这两天脖子有点儿难受，动弹不得，现在已经扩展到两肩了，痛苦啊！不过文章的提纲已经差不多了，这篇涉及的技术内容会比较多，又多是一些不太被了解的环节，所以要写的通俗易懂、老少咸宜——真是不容易啊，我尽力啦！：）

其实迄今为止我接触到的国内MVP都比较垃圾，这也怪不得你们，怪微软中国MVP的选择机制太滥了

@haha:

人无完人，不过希望每一个MVP都能以史为鉴，从我做起，通过不懈的努力来证明这个头衔的价值——希望这个目前在整体上还算credible的名称不会像其他的certification一样变得“incredible”！:)