blocks|key|322444|text|Spring-AOP的优点|type|unstyled|depth|inlineStyleRanges|entityRanges|data|322445|322446|它比AspectJ更容易使用，因为你不需要使用LTW+(load-time+weaving)或AspectJ编译器。|unordered-list-item|offset|length|322447|它使用代理模式和装饰器模式|322448|322449|Spring-AOP缺点|322450|322451|这是基于代理的面向方面编程，所以基本上你只能使用方法--在同一个类中调用另一个方法时不会应用执行overhead.|322452|Spring-AOP。|322453|可能会有一些运行时joinpoints.|322454|Aspects不能将方面添加到任何不是由|322455|工厂创建的内容中|322456|AspectJ的优点|322457|322458|这支持所有连接点。这意味着你可以做任何事情。|322459|与Spring+AOP相比，运行时开销更少。|322460|322461|AspectJ缺点|322462|322463|要小心。检查您的方面是否仅编织为您想要编织的内容。|322464|您需要使用AspectJ编译器执行额外的构建过程，或者必须设置LTW+(加载时编织)|322465|322466|entityMap|0|LINK|mutability|MUTABLE|url|http://www.eclipse.org/aspectj/doc/next/devguide/ltw.html^0|0|0|S|H|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1N|8|@]|9|@$F|1O|G|1P|1|1Q]]|A|$]]|$1|H|3|I|5|E|7|1R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1T|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1V|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1W|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|1X|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1Y|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|20|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|10|3|11|5|E|7|22|8|@]|9|@]|A|$]]|$1|12|3|13|5|E|7|23|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|25|8|@]|9|@]|A|$]]|$1|17|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|18|3|19|5|E|7|27|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|E|7|28|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|29|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|2A|8|@]|9|@]|A|$]]]|1E|$1F|$5|1G|1H|1I|A|$1J|1K]]]]

Spring-AOP Pros

<ul>
<li>It is simpler to use than AspectJ, since you don't have to use LTW (<a href="http://www.eclipse.org/aspectj/doc/next/devguide/ltw.html" rel="noreferrer">load-time weaving</a>) or the AspectJ compiler.</li>
<li>It uses the Proxy pattern and the Decorator
pattern</li>
</ul>

Spring-AOP Cons

<ul>
<li>This is proxy-based AOP, so basically you can only use method-execution joinpoints.</li>
<li>Aspects aren't applied when calling another method within the same class.</li>
<li>There can be a little runtime overhead.</li>
<li>Spring-AOP cannot add an aspect to anything that is not created by the Spring factory</li>
</ul>

AspectJ Pros

<ul>
<li>This supports all joinpoints. This means you can do anything. </li>
<li>There is less runtime overhead than that of Spring AOP.</li>
</ul>

AspectJ Cons

<ul>
<li>Be careful. Check if your aspects are weaved to only what you wanted to be weaved.</li>
<li>You need extra build process with AspectJ Compiler or have to setup LTW (load-time weaving)</li>
</ul>

blocks|key|427210|text|The+spring+user+manual将提供大量信息，这些信息都是直接从马的嘴里说出来的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|427211|6.4+-+Choosing+which+AOP+declaration+style+to+use这一章非常适合你，因为它讨论了两者的优缺点。|427212|段落6.1.2+-+Spring+AOP+Capabilites+and+goals+&+6.2+-+@Aspect+support和6.8+-+Using+AspectJ+with+Spring+applications应该特别有趣。|427213|entityMap|0|LINK|mutability|MUTABLE|url|http://static.springsource.org/spring/docs/2.5.x/reference/index.html|1|http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-choosing|2|http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-introduction-spring-defn|3|http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-ataspectj|4|http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-using-aspectj^0|0|M|0|0|0|1D|1|0|2|14|2|19|L|3|1V|18|4|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]|$A|19|B|1A|1|1B]|$A|1C|B|1D|1|1E]]|C|$]]|$1|H|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]|R|$5|K|L|M|C|$N|S]]|T|$5|K|L|M|C|$N|U]]|V|$5|K|L|M|C|$N|W]]]]

<a href="http://static.springsource.org/spring/docs/2.5.x/reference/index.html" rel="noreferrer">The spring user manual</a> will give a lot of information, straight from the horse's mouth. 

The chapter <a href="http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-choosing" rel="noreferrer">6.4 - Choosing which AOP declaration style to use</a> is dead on for you since it discusses the pros and cons of both.

The paragraph <a href="http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-introduction-spring-defn" rel="noreferrer">6.1.2 - Spring AOP Capabilites and goals</a> &amp; chapters <a href="http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-ataspectj" rel="noreferrer">6.2 - @Aspect support</a> and <a href="http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-using-aspectj" rel="noreferrer">6.8 - Using AspectJ with Spring applications</a> should be particularily interesting.

blocks|key|322519|text|除了其他人所说的--只是换个说法，there+are+two+major+differences|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|322520|322521|One与编织的类型有关。将|ordered-list-item|322522|另一个添加到连接点定义。|322523|322524|Spring-AOP:使用dynamic+proxy+if+interface+exists+or+cglib+library+if+direct+implementation+provided.概念通过代理进行运行时编织|BOLD|322525|AspectJ:编译时通过AspectJ+Java+Tools(ajc+compiler)编织(如果源代码可用)或编译后编织(使用编译文件)。此外，可以启用Spring的加载时编织-它需要aspectj定义文件并提供灵活性。|322526|编译时编织可以提供性能优势(在某些情况下)以及joinpoint+definition+in+Spring-aop+is+restricted+to+method+definition+only+which+is+not+the+case+for+AspectJ.|322527|entityMap^0|H|V|0|0|0|0|0|0|2Y|D|2D|0|0|8|D|W|2M|7|0|N|31|0^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|Z|8|@]|D|@]|E|$]]|$1|J|3|K|5|I|7|10|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|12|8|@$9|13|A|14|B|O]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|17|8|@$9|18|A|19|B|O]|$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|1E|8|@$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|T|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]]|U|$]]

Apart from what others have stated - just to rephrase, <code>there are two major differences</code>:

<ol>
<li>One is related to the type of weaving. </li>
<li>Another to the joinpoint definition.</li>
</ol>

Spring-AOP: Runtime weaving through proxy using concept of <code>dynamic proxy if interface exists or cglib library if direct implementation provided.</code>

AspectJ: Compile time weaving through <code>AspectJ Java Tools(ajc compiler)</code> if source available or post compilation weaving (using compiled files). Also, load time weaving with Spring can be enabled - it needs the <code>aspectj</code> definition file and offers flexibility.

Compile time weaving can offer benefits of performance (in some cases) and also the <code>joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.</code>

blocks|key|427239|text|补充说明：如果在高负载下的性能很重要，那么您将需要比Spring+AOP快9-35倍的AspectJ。10+vs+vs+355+vs听起来可能不是很多，但我已经看到人们使用了很多方面。价值10K的方面。在这些情况下，您的请求可能涉及数千个方面。在这种情况下，您将向该请求添加ms。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|427240|请参阅benchmarks。|427241|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.codehaus.org/display/AW/AOP%2BBenchmark^0|5|V|0|3|A|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@]|D|@$9|T|A|U|1|V]]|E|$]]|$1|H|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

An additional note: If performance under high load is important, you'll want AspectJ which is 9-35x faster than Spring AOP. 10ns vs 355ns might not sound like much, but I've seen people using LOTS of Aspects. 10K's worth of aspects. In these cases, your request might hit a thousands of aspects. In that case you're adding ms to that request.

See the <a href="http://docs.codehaus.org/display/AW/AOP+Benchmark">benchmarks</a>.

blocks|key|322624|text|Spring+AOP是spring框架的重要组成部分之一。在最基本的阶段，spring框架是基于IoC和面向方面编程的。在Spring的官方课程中，有一张幻灯片说：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|322625|面向方面编程|322626|是框架中最重要的部分之一。|blockquote|322627|322628|322629|理解Spring中面向方面编程的关键点是，当您使用Spring编写方面时，我们通过为您的对象构建代理来检测框架，如果您的bean实现了一个接口，则使用JDKDynamicProxy；如果您的bean没有实现任何接口，则通过CGLIB进行检测。请记住，如果您使用的是版本3.2之前的Spring，则类路径中必须有cglib+2.2。从Spring3.2开始，它是无用的，因为核心中包含了cglib+2.2。|offset|length|style|CODE|322630|在创建bean时，框架将创建一个代理，该代理包装您的对象并添加横切关注点职责，如安全性、事务管理、日志记录等。|322631|以这种方式创建的代理将从一个切入点表达式开始应用，该表达式检测框架以确定哪些bean和方法将被创建为代理。建议将是更多的责任，而不是你的代码。请记住，在此过程中，切入点只捕获未声明为final的公共方法。|322632|现在，在Spring+AOP中，方面的编织将在容器启动时由容器执行，而在AspectJ中，您必须通过字节码修改对代码进行后期编译来执行这一操作。因此，在我看来，Spring方法比AspectJ更简单、更易于管理。|322633|另一方面，对于Spring+AOP，您不能使用AOP的所有功能，因为实现是通过代理来完成的，而不是通过修改代码来完成的。|322634|与在AspectJ中一样，您可以在SpringAOP中使用加载时编织。您可以在spring中使用代理和特殊配置(+@EnabledLoadWeaving或XML语言)实现此功能。您可以使用名称空间作为示例。然而，在Spring+AOP中，您不能拦截所有情况。例如，Spring+AOP不支持new命令。|322635|但是，在Spring+AOP中，通过在spring配置bean中使用aspectof工厂方法，您可以从AspectJ的使用中获益。|322636|因为Spring+AOP基本上是从容器创建的代理，所以您只能将AOP用于spring+bean。而使用AspectJ时，您可以在所有bean中使用方面。另一个比较点是调试和代码行为的可预测性。使用spring+AOP，这项工作完全是从Java编译器执行的，方面是为Spring+bean创建代理的一种非常酷的方式。在AspectJ中，如果你修改了代码，你需要更多的编译，并且理解你的方面是在哪里编织的可能很困难。甚至在spring中关闭编织也更简单:使用spring，您可以从配置中删除方面，然后重新启动，它就可以工作了。在AspectJ中，你必须重新编译代码！|322637|在加载时编织中，AspectJ比Spring更灵活，因为Spring并不支持AspectJ的所有选项。但在我看来，如果您想要更改bean的创建过程，更好的方法是在工厂中管理自定义登录，而不是使用会更改新操作员行为的方面的加载时编织。|322638|我希望这篇AspectJ和Spring+AOP的全景文章能帮助您理解这两种方法的区别|322639|entityMap^0|0|0|0|0|0|23|F|0|0|0|0|0|1L|J|41|3|0|Y|8|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1A|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1D|8|@$K|1E|L|1F|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1H|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1I|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1J|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1K|8|@$K|1L|L|1M|M|N]|$K|1N|L|1O|M|N]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1P|8|@$K|1Q|L|1R|M|N]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1S|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1T|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1U|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|17|$]]

Spring AOP is one of the essential parts of the spring framework. At the very basic stage, the spring framework is based on IoC and AOP. In the official course of Spring there is a slide in which it says:

<blockquote>
 The AOP is one of the most important parts of the framework.
</blockquote>

The key point for understanding how AOP in Spring works is that when you write an Aspect with Spring we instrument the framework with building a proxy for your objects, with a <code>JDKDynamicProxy</code> if your bean implements an interface or via CGLIB if your bean doesn't implement any interface. Remember that you must have cglib 2.2 in your class-path if you're using Spring prior to version 3.2. Starting from Spring 3.2 it is useless because cglib 2.2 was included in the core.

The framework at the bean creation will create a proxy that wraps your objects and adds cross cutting concerns responsibilities such as security, transaction management, logging and so on.

The proxy creation in this way will be applied starting for a pointcut expression that instruments the framework to decide what beans and methods will be created as proxies. The advice will be the more responsibility than for your code. Remember that in this process the pointcut captures only public methods that aren't declared as final.

Now, while in Spring AOP the weaving of Aspects will be performed by the container at container start-up, in AspectJ you have to perform this with a post compilation of your code through bytecode modification. For this reason in my opinion the Spring approach is simpler and more manageable than AspectJ.

On the other hand, with the Spring AOP you can't use the all power of AOP because the implementation is done through proxies and not with through modification of your code.

As in AspectJ, you can use load-time weaving in SpringAOP. You can benefit from this feature in spring is implemented with an agent and special configurations, <code>@EnabledLoadWeaving</code> or in XML. You can use the name-space as an example. However in Spring AOP you can't intercept all the cases. For example, the <code>new</code> command isn't supported in Spring AOP.

However in Spring AOP you can benefit from the usage of AspectJ through the use of the <code>aspectof</code> factory method in the spring configuration bean.

For the reason that Spring AOP is basically a proxy created from the container, so you can use AOP only for spring beans. While with AspectJ you can use the aspect in all your beans. Another point of comparison is debug and the predictability of the code behavior. With spring AOP, the job is preformed all from the Java compiler and aspects are a very cool way for creating proxy for your Spring bean. In AspectJ if you modify the code, you need more compiling and to understand where your aspects are woven could be hard. Even shutting down the weaving in spring is simpler: with spring you remove the aspect from your configuration, restart and it works. In AspectJ you must recompile the code!

In load-time weaving, AspectJ is more flexible than Spring because Spring doesn't support all of the options of AspectJ. But in my opinion If you want to change the creation process of a bean, a better way is to manage the custom login in a factory and not with load-time weaving of an aspect that changes the behavior of your new operator.

I hope that this panoramic of AspectJ and Spring AOP helps you understand the difference of the two potions

blocks|key|322693|text|重要的是要考虑你的方面是否是任务关键型的，以及你的代码被部署在哪里。Spring+AOP将意味着您依赖于加载时编织。这可能会失败，在我的经验中，这意味着可能存在记录的错误，但不会阻止应用程序在没有方面代码的情况下运行[我要补充说明的是，可以以一种不是这种情况的方式配置它；但我个人没有意识到这一点]。编译时编织避免了这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|322694|此外，如果您将AspectJ与aspectj-maven-plugin结合使用，那么您就能够在CI环境中针对您的方面运行单元测试，并确信构建的工件已经过测试并正确编织。虽然您肯定可以编写Spring驱动的单元测试，但您仍然不能保证在LTW失败的情况下部署的代码将是经过测试的代码。|322695|另一个注意事项是，您是否在能够直接监控服务器/应用程序启动成功或失败的环境中托管应用程序，或者是否在不受您监管的环境中部署应用程序，例如，在客户端托管的环境中。同样，这将为编译时间编织指明方向。|322696|五年前，我更喜欢Spring配置的AOP，原因很简单，因为它更容易使用，而且不太可能消耗我的IDE。然而，随着计算能力和可用内存的增加，这已经不是什么问题了，基于我上面概述的原因，带有aspectj-maven-plugin的CTW已经成为我工作环境中更好的选择。|322697|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

It is important to consider whether your aspects will be mission critical and where your code is being deployed. Spring AOP will mean that you are relying on load-time weaving. This can fail to weave and in my experience has meant that logged errors may exist but will not prevent the application from running without aspect code [I would add the caveat that it may be possible to configure it in such a way that this is not the case; but I am not personally aware of it]. Compile-time weaving avoids this. 

Additionally, If you use AspectJ in conjunction with the aspectj-maven-plugin then you are able to run unit tests against your aspects in a CI environment and have confidence that built artifacts are tested and correctly woven. While you can certainly write Spring driven unit tests, you still have no guarantee that the deployed code will be that which was tested if LTW fails.

Another consideration is whether you are hosting the application in an environment where you are able to directly monitor the success or failure of a server / application startup or whether your application is being deployed in an environment where it is not under your supervision [e.g. where it is hosted by a client]. Again, this would point the way to compile time weaving.

Five years ago, I was much more in favour of Spring configured AOP for the simple reason that it was easier to work with and less likely to chew up my IDE. However, as computing power and available memory have increased this has become much less of an issue and CTW with the aspectj-maven-plugin has become a better choice in my work environment based on the reasons I have outlined above.

blocks|key|427328|text|这篇article也有关于这个主题的很好的解释。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|427329|427330|+Spring+AOP和AspectJ有着不同的目标。|blockquote|427331|427332|Spring+AOP的目标是在Spring+IoC中提供一个简单的AOP实现，以解决程序员面临的最常见的问题。|427333|另一方面，AspectJ是最初的面向方面编程技术，旨在提供完整的面向方面编程解决方案。|427334|entityMap|0|LINK|mutability|MUTABLE|url|https://www.baeldung.com/spring-aop-vs-aspectj^0|2|7|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

This <a href="https://www.baeldung.com/spring-aop-vs-aspectj" rel="nofollow noreferrer">article</a> also has a good explanation regarding the topic.
<blockquote>
Spring AOP and AspectJ have different goals.
Spring AOP aims to provide a simple AOP implementation across Spring
IoC to solve the most common problems that programmers face.
On the other hand, AspectJ is the original AOP technology which aims to
provide complete AOP solution.
</blockquote>

blocks|key|1726760|text|与面向方面编程相比，AspectJ不需要在编译时增强目标类。相反，它在运行时为目标类生成一个代理类，该代理类要么实现与目标类相同的接口，要么是目标类的子类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1726761|总而言之，代理类的实例可以用作目标类的实例。通常，编译时增强型AOP框架在性能上更有优势-因为运行时增强型AOP框架每次运行时都需要动态增强。|1726762|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Compared to AOP, AspectJ does not need to enhance the target class at compile time. Instead, it generates a proxy class for the target class at runtime, which either implements the same interface as the target class or is a subclass of the target class. 
In summary, an instance of a proxy class can be used as an instance of a target class. In general, the compile-time enhanced AOP framework is more advantageous in performance—because the runtime-enhanced AOP framework requires dynamic enhancements every time it runs.

I am under the impression that Spring AOP is best used for application specific tasks such as security, logging, transactions, etc. as it uses custom Java5 annotations as a framework. However, AspectJ seems to be more friendly design-patterns wise. 

Can anyone highlight the various pros and cons of using Spring AOP vs AspectJ in a Spring application?

Spring AOP vs AspectJ

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我的印象是Spring AOP最适合用于特定于应用程序的任务，如安全性、日志记录、事务等，因为它使用自定义的Java5注释作为框架。然而，在设计模式方面，AspectJ似乎更加友好。有人能强调在Spring应用程序中使用Spring AOP和AspectJ的各种优缺点吗？

问Spring AOP vs AspectJ
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Spring AOP vs AspectJEN