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 ：
- 一个与织造的types有关。
- 另一个连接点定义。
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的这个全景图可以帮助你理解两种魔药的区别
