1. Spring AOP
It is implemented in pure Java, so it
doesn’t require a special compilation process or a special class loader to
compile the aspects.
It is a proxy based implementation, which
means Spring generates a proxy object for the target object and it will
intercept any requests to the target object and it invokes the appropriate
advice method of the aspect, depending on the type of the advice (before,
after, after throwing or around) which is applied at the target object method
and also invokes the target method.
It supports schema based XML
configuration with/without AspectJ or AspectJ annotation configuration. Both
are pure Java implementations. Aspects can be configured as normal spring
beans. Depending on the spring AOP configuration, spring generates proxy
objects for the target objects.
1.1 Advantages of Spring AOP
1. It is non-invasive
a.
Your service/domain classes get advised by the aspects (cross
cutting concerns) without adding any Spring AOP related classes or interfaces into
the service/domain classes.
b. Allows the developer to
concentrate on the business code, instead the cross cutting concerns.
2. Its implemented in pure
Java
a.
No need for a special compilation unit, or a special class
loader
3. It uses Spring’s IOC for
dependency injection
a.
Aspects can be configured as normal spring beans.
4. As any other AOP
framework, it weaves cross cutting concerns into the classes, without making a
call to the cross cutting concerns from those classes.
5. Centralize or modularize
the cross cutting concerns
a.
Easy to maintain and make changes to the aspects
b. Changes need to be made in
one place.
c.
In one of your classes you don’t want to have logging, it can
easily be achieved by modifying the point cut in the respective aspect (logging
aspect). So you need to make changes in only one place.
6. Provision to create
aspects using schema based (XML configuration) or @AspectJ annotation based
style.
7. Easy to configure
1.2 Disadvantages or Limitations of Spring AOP
1. A little difficult to
debug the AOP based application code.
a.
Since the business classes are advised behind the scene with
aspects.
2. Since it uses proxy based AOP, only method
level advising is supported, doesn’t support field level interception
a.
So your join-point can be at method level not at field level
in a class.
3. Only methods with public
visibility will be advised
a.
Methods with protected, private or default visibility will
not be advised.
4. A little runtime overhead,
but its negligible
a.
The overhead is in nanoseconds.
5. Aspects cannot advise
other Aspects - Not possible to have aspects to be the target of advice from
other aspects.
a.
Because once you mark one class as an aspect (either using
XML or annotation), spring excludes it from being auto-proxied.
6. Local or internal method
calls within an advised class doesn’t
get intercepted by proxy, so advise method of the aspect does not get
fired/invoked
a.
For example, say you have a service class with two public
methods saveUser() and savRole(), both are advised by a logging aspect (aspect
for cross cutting concern - logging). If
a client (Controller) invokes these methods individually, then the advice
method of the loggingAspect gets invoked. But if you call saveRole() method
from saveUser() method (a method call within the same class) then the advice
method will not get invoked, though saveRole() method is captured by the AOP
point-cut.
7. Is not for advising
fine-grained objects (domain objects), it is best suitable for coarse grained
objects (Service ..)due to performance.
a.
This depends on your requirement. Say your application is not
so big, and then you can very well use Spring AOP, because the performance
impact due to Spring AOP will be negligible as the number of methods involved
to serve a request will not be very high.
ReplyDeletethanks