Disadvantages of AOP

A little difficult to debug the AOP based application code.

• Since the business classes are advised behind the scene with aspects.

Since it uses proxy based AOP, only method level advising is supported, doesn’t support field level interception

• So your join-point can be at method level not at field level in a class.

Only methods with public visibility will be advised

• Methods with protected, private or default visibility will not be advised.

A little runtime overhead, but its negligible

• The overhead is in nanoseconds.

Aspects cannot advise other Aspects - Not possible to have aspects to be the target of advice from other aspects.

• Because once you mark one class as an aspect (either using XML or annotation), spring excludes it from being auto-proxied.

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

• 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.

Is not for advising fine-grained objects (domain objects like pojo), it is best suitable for coarse grained objects (Service ...) due to performance.

• 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.