If you decide that using an aspect is the best approach for a given task, how do you know whether to use Spring AOP or AspectJ, and whether to choose the Aspect language (code) style, the @AspectJ annotation style, or the Spring XML style? This choice is influenced by a number of factors, including application requirements, development tools, and the team's familiarity with AOP.
Spring AOP or full-featured AspectJ?
Use the simplest solution that will work. Spring AOP is easier to use than full-featured AspectJ because there is no need to implement the compiler/linking tool from AspectJ into the development and build processes. If you only need to manage the execution of operations on Spring beans, then Spring AOP is the right choice. If you need to provide advice to objects that are not under the control of the Spring container (for example, domain objects, typically), then you need to use AspectJ. You should also use AspectJ if you need to provide hints to join points other than simple method executions (for example, field get or set join points, etc.).
If you use AspectJ, you can choose between the AspectJ language syntax (also known as the "code style") and the @AspectJ annotation style. Obviously, if you are not using Java 5+, then the choice is already made for you: Use a code style. If aspects play a big role in your project and you can use the AspectJ Development Tools (AJDT) plugin for Eclipse , AspectJ language syntax is the preferred option. It is cleaner and simpler because the language was specifically designed for writing aspects. If you don't use Eclipse or have just a few aspects that don't play a big role in the application, you might consider using the @AspectJ style, sticking with normal Java compilation in your IDE, and adding an aspect binding step to your build script.
@AspectJ or XML for Spring AOP?
If you decide to use Spring AOP, you can choose between @AspectJ or XML style. There are various trade-offs to consider.
The XML style may be most familiar to existing Spring users, and it is supported by true POJOs. When using AOP as a tool for configuring enterprise services, XML may be a good choice (the proper test would be if you answer the question whether you think the slice expression will be part of your configuration that you might need to change independently) . XML style will make it clearer from your configuration which aspects are present in the system.
The XML style has two disadvantages. First, it does not completely encapsulate the implementation of the problem it solves in one place. The Don't repeat yourself/DRY principle states that each piece of knowledge should have a single, consistent, and authoritative representation within the system. When using XML style, knowledge of how a task is implemented is distributed between the base bean class declaration and XML in the configuration file. If you use the @AspectJ style, then this information is contained in one module: the aspect. Second, the XML style is a bit more limited than the @AspectJ style in terms of expressiveness: Only the model of creating single instances of an aspect is supported, and it is not possible to concatenate named slices declared in XML. For example, when using the @AspectJ style, you could write something like:
@Pointcut("execution(* get*())")
public void propertyAccess() {}
@Pointcut("execution(org.xyz.Account+ *(..))")
public void operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
public void accountPropertyAccess() {}@Pointcut("execution(* get*())")
fun propertyAccess() {}
@Pointcut("execution(org.xyz.Account+ *(..))")
fun operationReturningAnAccount() {}
@Pointcut("propertyAccess() && operationReturningAnAccount()")
fun accountPropertyAccess() {}You can declare the first two slices in XML style:
<aop:pointcut id="propertyAccess"
expression="execution(* get*())"/>
<aop:pointcut id="operationReturningAnAccount"
expression="execution(org.xyz.Account+ *(..))"/>The disadvantage of the XML approach is that you cannot define an accountPropertyAccess slice by
combining these definitions.
The @AspectJ style supports additional instantiation models and richer slice composition. Its advantage is to keep the aspect as a modular unit. Another advantage is also that @AspectJ aspects can be recognized (and therefore used) by both Spring AOP and AspectJ. This way, if you later decide that additional tasks require AspectJ capabilities, you can easily switch to the classic AspectJ configuration. In general, the Spring team favors the @AspectJ style for special aspects that go beyond simple enterprise service configuration.
Mixed use of aspect types
It is perfectly acceptable to mix and match aspects in the same configuration, written in the @AspectJ style, using
auto-proxy tools defined by the aspect schema <aop:aspect>, declared advisors <aop:advisor>
and even proxies and interceptors written in other styles. They are all implemented using the same
basic support mechanism and can coexist without any problems.
GO TO FULL VERSION