Spring AOP与AspectJ

我认为Spring AOP最适合用于特定于应用程序的任务,如安全性,日志logging,事务处理等,因为它使用自定义的Java5注释作为框架。 然而,AspectJ似乎是更加友好的devise模式。

任何人都可以突出显示在Spring应用程序中使用Spring AOP与AspectJ的各种利弊吗?

springAOP赞成

  • 使用比AspectJ更简单,因为您不必使用LTW( 加载时织入 )或AspectJ编译器。

  • 这使用代理模式和装饰模式

Spring-AOP缺点

  • 这是基于代理的AOP,所以基本上只能使用方法执行连接点。
  • 在同一个类中调用另一个方法时不会应用方面。
  • 可能会有一点运行时间的开销。
  • Spring-AOP不能将一个方面添加到不是由Spring工厂创build的任何东西

AspectJ优点

  • 这支持所有的连接点。 这意味着你可以做任何事情。
  • 运行时间比Spring AOPless。

AspectJ缺点

  • 小心。 检查你的方面是否只编织到你想要编织的东西。
  • 您需要使用AspectJ Compiler进行额外的构build过程,或者必须设置LTW(加载时编织)

除了别人所说的 – 只是为了重述, there are two major differences

  1. 一个与织造的types有关。
  2. 另一个连接点定义。

Spring-AOP:运行时通过代理使用dynamic proxy if interface exists or cglib library if direct implementation provided.概念, dynamic proxy if interface exists or cglib library if direct implementation provided.

AspectJ:通过AspectJ Java Tools(ajc compiler)编译时间,如果源可用或编译后编译(使用编译文件)。 另外,可以启用使用Spring aspectj加载时间 – 它需要aspectj定义文件并提供灵活性。

编译时织入可以提供性能上的好处(在某些情况下),而且joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

spring的用户手册会给出很多信息,直接从马的嘴里。

第6.4章- select使用哪种AOP声明风格已经死了,因为它讨论了两者的优点和缺点。

第6.1.2节 – Spring AOP Capabilites和目标和章节6.2 – @Aspect支持和6.8 – 在Spring应用程序中使用AspectJ应该特别有趣。

另外需要注意的是: 如果高负载下的性能很重要,那么你会希望AspectJ比Spring AOP快9-35倍 。 10ns vs 355ns可能听起来不怎么样,但我已经看到人们使用LOTS的方面。 10K的价值方面。 在这些情况下,您的请求可能会涉及到数千个方面。 在这种情况下,您正在向该请求添加ms。

看基准 。

Spring AOP是Spring框架的重要组成部分之一。 在最基本的阶段,Spring框架是基于IoC和AOP的。 在春季的正式课程中有一个幻灯片,其中说:

AOP是框架中最重要的部分之一。

理解Spring如何运行AOP的关键在于,当你使用Spring编写一个Aspect时,我们使用JDKDynamicProxy为你的对象构build一个代理,如果你的bean实现了一个接口,或者通过CGLIB(如果你的bean没有实现的话)任何界面。 请记住,如果您使用3.2之前的Spring,则必须在类path中包含cglib 2.2。 从Spring 3.2开始,它是无用的,因为cglib 2.2被包含在内核中。

创buildbean的框架将创build一个包装对象的代理,并增加跨安全性,事务pipe理,日志logging等交叉事务的职责。

以这种方式创build代理将从一个切入点expression式开始应用,这个切入点expression式将决定哪些bean和方法将被创build为代理。 build议将是比你的代码更多的责任。 请记住,在这个过程中,切入点只捕获未声明为最终的公共方法。

现在,在Spring AOP中,方面的编织将由容器在容器启动时执行,在AspectJ中,您必须通过字节码修改后的代码编译来执行此操作。 基于这个原因,我认为Spring方法比AspectJ更简单,更易于pipe理。

另一方面,使用Spring AOP,您不能使用AOP的全部function,因为实现是通过代理完成的,而不是通过修改代码来完成的。

和AspectJ一样,你可以在SpringAOP中使用加载时织入。 你可以从这个特性中受益,在spring中使用代理和特殊的configuration, @EnabledLoadWeaving或XML。 您可以使用名称空间作为示例。 但是,在Spring AOP中,不能拦截所有的情况。 例如,Spring AOP不支持new命令。

然而,在Spring AOP中,通过在springconfigurationbean中使用工厂方法的方面,您可以从AspectJ的使用中aspectof

因为Spring AOP基本上是一个从容器创build的代理,所以你可以使用AOP只适用于spring bean。 而使用AspectJ,你可以在所有的bean中使用这个方面。 另一个比较点是debugging和代码行为的可预测性。 使用Spring AOP,所有这些工作都是从Java编译器中完成的,而这些方面对于为您的Spring bean创build代理非常酷。 在AspectJ中,如果你修改代码,你需要更多的编译和理解你的方面编织可能是困难的。 即使在springclosures编织也很简单:用弹簧从configuration中移除该方面,重新启动并运行。 在AspectJ中,你必须重新编译代码!

在加载时编织中,AspectJ比Spring更灵活,因为Spring不支持AspectJ的所有选项。 但在我看来,如果你想改变一个bean的创build过程,一个更好的方法是pipe理工厂中的自定义login,而不是用一个方面的加载时编织来改变你的新运算符的行为。

我希望AspectJ和Spring AOP的这个全景图可以帮助你理解两种魔药的区别