对Spring的AOP体系的一些个人想法

（1）首先spring 的aop体系兼容了spring 的javabeans的配置和IOC的配置体系形成了比较风格统一，正因为spring作者Rod Johnson是aopalliance定制人之一，理所当然的spring也支持和遵守aopalliance的规范。从他的内核看来并不复杂就是通过Cglib和JDK动态代理这两种方式实现的,默认是Cglib的方式.
（2）Spring的AOP体系实现的重扩展和开放的角度看是比较完美的，但是我个人觉得（不知道对不对的,大家就看看的心态好了,自己鉴别好了)，使用的复杂性和AOP的开关原则又存在一些弊端（哈哈有点自大了，竟然攻击Johnson）：AOP是从更广的抽象正交分离关注点,但是使用Spring的AOP体系方式并没有使织入者与被织入者的关系分离(因为你还是必须写一个的类实现MethodInterceptor,把两者的织入关系代码里写)这就必须让使用者的AOP观念很强才能正常使用,初学者很难去理解.
(3)我自己认为,可以简单的使用配置声明织入者,被织入者和织入点(织入方式:befor/after),和织入的方法函数和被织入的方法函数,那么后台就能通过一个工厂直接形成一个Advisor(完全扮演了一个横切观念，包括被织入的代码片断和织入点----代理顾问)再根据其完全可以实现一些AOP的操作，而不需要再手工去处理那么多逻辑。不可否认这样的开关决策必然会降低开放性和用户的参与和改造能力，但是还是有机会可以补偿的：可以开放一个核心的实现例如Cglib2AopProxy.java和JdkDynamicAopProxy给一些有志改造或需要的人员进行继承派生就行了。毕竟AOP的核心观念就是织入者，被织入者，织入点和织入的条件。织入的情况大多就是之前，之后，还有就是一段代码中（同时有之前之后）.根本就可以创造一个AOP体系完成织入的用户定义的逻辑。
（4）说了一些个人觉得说缺点的地方，我也觉得有一些偏激了，我是多么的尊敬Rod Johnson的毕竟他是我们这些人的前辈同时很无私的提供很多优秀的观念给我们，是时候也要说一说Spring AOP中很好的地方，第一他把AOP的过程分的更细了（我并没有很详细的看的代码体系，只是从接口的编排和一些比较核心代码理解的），在每一个环节中很好的分离面出来。提供了很多优化服务：例如Cache，区分单实例，和非单实例实现；同时也提出支持配置过滤函数名的织入方法,也提供了不少虚类,给用户去改造(但是框架改造的难度比较大,还不如自己写了)
（5）我自己正着手写包含一个简单AOP体系的开源项目,如果大家有什么不同的看法或觉得我说的不对的地方请指出来,小弟十分的感谢.

recher 至少是有理性精神的人，recher 指出了Spring对AOP实现的一些不足，我觉得以后版本它会开放它的核心的实现例如Cglib2AopProxy.java和JdkDynamicAopProxy，因为这些地方都是有待改进的地方，特别是J2SE 1.5出来后，这些地方可以使用新的特性，能更简捷和高效。

虽然Spring内部实现AOP复杂，但是使用起来还是比较简单，使用者基本无需AOP概念，就可以配置Spring的文件，这点我认为是Spring的极大贡献阿。

板桥大哥：您好，我的想法是如果用户使用AOP的框架，连拦截器都不用写，例如我现在想构想一个改良的框架：用户只需要编写两个类：被织入的类，和织入的类，然后通过配置文件的定义，框架会有一个自动拦截器制造工厂，完成织入的动作不需要用户去关心。例如可以采取以下的配置方式：
<AOP>
<TargetClass>Sourcetarget</TargetClass>
<Weavings>
<TargetClassMethod>method1</TargetClassMethod>
<WeavingsClass>
<WeavingClass>Class1</WeavingClass>
<WeavingMethod>
<Method>method1</Method>
<Mode>befor</Mode>
</WeavingMethod>
<WeavingMethod>
<Method>method2</Method>
<Mode>befor</Mode>
</WeavingMethod>
</WeavingsClass>
<WeavingsClass>
<WeavingClass>Class2</WeavingClass>
<WeavingMethod>
<Method>method3</Method>
<Mode>befor</Mode>
</WeavingMethod>
<WeavingMethod>
<Method>method4</Method>
<Mode>afert</Mode>
</WeavingMethod>
</WeavingsClass>
</Weavings>
</AOP>

[AOP]
[TargetClass]Sourcetarget[TargetClass]
[Weavings]
[TargetClassMethod]method1[TargetClassMethod]
[WeavingsClass]
[WeavingClass]Class1[WeavingClass]
[WeavingMethod]
[Method]method1[Method]
[Mode]befor[Mode]
[WeavingMethod]
[WeavingMethod]
[Method]method2[Method]
[Mode]befor[Mode]
[WeavingMethod]
[WeavingsClass]
[WeavingsClass]
[WeavingClass]Class2[WeavingClass]
[WeavingMethod]
[Method]method3[Method]
[Mode]befor[Mode]
[WeavingMethod]
[WeavingMethod]
[Method]method4[Method]
[Mode]afert[Mode]
[WeavingMethod]
[WeavingsClass]
[Weavings]
[AOP]

哈哈非常棒，你的这个想法其实已经被EJB的ejb-jar.xml文件实现，看看E下面配置文件一段：

<assembly-descriptor>
<security-role>
<description>the role is super user </description>
<role-name>Admin</role-name>
</security-role>
<security-role>
<description>register user</description>
<role-name>User</role-name>
</security-role>

<method-permission>
<role-name>User</role-name>
<method>
<ejb-name>RoleManager</ejb-name>
<method-name>*</method-name>
</method>

</method-permission>
…
</assembly-descriptor>

这段配置是告诉EJB容器只有User角色才能访问RoleManager某个方法或所有方法，那么EJB容器是如何实现的？JBoss 4.0这样基于AOP的EJB容器就是使用了拦截器原理来实现。

同样，EJB事务机制也是在JBoss 4.0中使用AOP实现，不必象Spring那样要配置一个事务拦截器。

不知我说明白没有？

上贴配置内容如下，发贴时要使用Code按钮。详细内容可见：

http://www.jdon.com/mybook/details/6.htm


<assembly-descriptor>

<security-role>

<description>the role is super user </description>

<role-name>Admin</role-name>

</security-role>

<security-role>

<description>register user</description>

<role-name>User</role-name>

</security-role>

<method-permission>

<role-name>User</role-name>

<method>

<ejb-name>RoleManager</ejb-name>

<method-name>*</method-name>

</method>

</method-permission>

…

</assembly-descriptor>

先谢谢板桥大哥的提示（您说的够明白的），其实我也觉得这种想法和JBOSS 4.0有一点类似（调用的效果是一样的，但是JOBSS的实现AOP又和Spring的AOP又有所区别，JBOSS不是全部动态决定加载的--只能说是半自动吧毕竟他是一种中间件的角色，但是我们开发的应用系统就不可能采取他的方式了）,所以还是希望能使用aopalliance的绿色规范，来完成一种AOP的开发规范。Spring 并不是不好，对我们来说是很好的一个方向，我们可以沿着这种方向前进和改良他的实现，更能为自己和别人更能方便使用。同时觉得兼容aopalliance（提倡一种规范也是很有必要的，毕竟规范这东西对扩展整合都有好处---就象USB接口一样），我也很期待JDK 1.5 的来临，看一下他到底在那些方面给我们带来更多的支持特别是在(动态性，模板性，以及ClassLoader的RMI的特性).如果幸运的话可能给我们提供实现的AOP更加方便和提供更好实现。

是的，不错。我也在做。

我主要是根据AOP的思想，来做的，当然仔细分析起来也不很彻底，我觉得，这东西就如同原来的疯狂的面接口一样，关键是根据实际情况取舍。毕竟，公司真正明白AOP,IOC的太少，这么做起来，特别是实际的项目团队效果不是很好。

鲁中正气:
您好，没有错，你说的我也有感触，但是我觉得AOP的思路比较开阔，他是面的特点，使用AOP的技术特别注意场景的应用环境中（适当的环境使用适当的技术决策---说简单做到是没有恒定的规则靠的很大因素可能是经验和别人实施的经验），当然也可以应用在小的方面可以是一个类或函数之间（这种方法我不提倡，毕竟这样做的目标没有明确：正交分离的原则，如果连为什么用它都没考虑清楚或不客观的话，那么就导致你的实现也是存在天生和不可预测的缺陷和风险-----这就是人们常说不要为了技术而技术吧。接口的编程是很有例的，我个人觉得接口编程的作用往往比我的想象还要大（总有一些意外的收获），但并不代表我提倡什么都使用接口，我个人觉得使用接口的场景（由大到细）：层次间组件间的对外（使用者）开放一些和关闭一些--开关原则，对功能实现的考虑变化和扩展需要多态和模式应用，对某些复杂和比较耦合功能包你比较注重他的重用和可读可维护性多过它的性能和开发时间的角度规划。

to recher ,
真是道友阿，我最近对面向接口变程又有很高的提高了。呵呵，基本可以灵活运用了，现在再看那些GOF的23种模式，感慨万千，很简单的东西，何必搞出那么多的概念，即便现在，有人来问我这个到底是什么模式，真的吗？我也要犹豫一下，我真是感觉GOF那些模式真是水到渠成。
另外，网上，有个男孩女孩的文章，不错，但是最后给的那个例子，真是很误导“观众”，感觉其实真不该那么用。这篇文章对什么是的问题确实说的很好。但是怎么用，没有说好。对他们又制造了些新概念，也是比较讨厌。我觉的我们应该主要看他们在技术上，在代码上到底有哪些变化，无论这个方法叫什么，无论这个类叫什么。在看看指导他们的思想，即多问个为什么。

另外，我对如何应用aop,ioc,面向表编程，面向接口编程。。。也有些体会。
我现在总结了三大绝招，呵呵。何时应用？答：当发现，闻到一些需要提取的东西时（可以重用，但又不好提取时），有些地方以后可能要变化时，设计出现难题，或不自在时。这时开始想想以上那些东西。怎么应用？有何联系？
答：以面向表编程为坐标感，以面向接口编程为手段，以aop为思想，以重构为补充，以soa为理想，巧妙构造参数，提升命名艺术，方可以达到优雅的境界，取得前所未有的，超出想象的高效率，稳定性。
不知banq大哥和recher又和体会。呵呵。

另外再补充一下，ioc是aop的关键手段。

to鲁中正气:
听你一席话很有收获，我以前也是这样想过这样的问题（现在再看那些GOF的23种模式，感慨万千，很简单的东西，何必搞出那么多的概念，即便现在，有人来问我这个到底是什么模式。。。。），但是后来我个人觉得模式在个人的发展中不是什么法律只是一些用来作为沟通的标准而已，但是在一些复杂和混乱的业务需求中却很难用一种模式来弄清楚程序的设计的-----模式常常是小范围的功能设计的（但不是绝对，如果用得好抽象出来层次或其他大的方面也适用，就是难度和可读性就相对加大了），而AOP和接口比模式的就应用更加广（AOP应该比Interface更广）;我还有一个观点就是模式并不是死的，我觉得很多人使用模式都没有抱着一种创新和改造和集成使用导致模式的作用多于形式。而接口使用往往能作用大于形式，所以一些习惯考虑到一定清楚地人就写代码的人就会疯狂的接口编成。

to鲁中正气:
您所说的ioc是aop的关键手段这话我有些话要说，个人觉得可以是对因为他们的确有异曲同工之妙，而AOP有些地方是从IOC的基础上角度考虑的；也可以说不对，但是他们的实现的手段不同，导致应用的场景也不一样追求的目标也不一样。我觉得两者最好不要比较，因为他们没有冲突也不存在对抗，两者以客观的角度来评定可能更好。两者的关系就像C++和JAVA 的关系完全没有必要讨论谁好谁坏。IOC还会继续发展下去，AOP也是。但是有些东西我们要注意的：IOC(特别是SPring中的IOC)现在应用和AOP（Spring/Jboss4.0）的应用有着一个不容忽视的不同特点：IOC在要进行DI(注入）的类中先在类中注明成员-----这就说明IOC适合已经有比较清晰的关系功能类的关系（相对AOP有好有坏：好的是类型安全性提高，不好缺乏弹性），AOP这方面反之。这就提醒我们如何选者两者的一个标准之一（这是从技术的角度考虑的,当然还有一个更重要的就是从业务和框架上考虑）。