Tuesday, April 26, 2011

AOP introduction

Need For AOP
First see need for aop.

Defining AOP
Aspect-Oriented Programming (AOP) complements Object-Oriented Programming (OOP) by providing another way of thinking about program structure.

Aspects are concern of the application that apply themselves across the entire system. The SecurityManager is one example of system-wide aspect, as its hasPermissions methods are used by many methods. Other typical aspects include logging, auditing, exception handling, performance monitoring, transaction management. See need for aop . These are also called advice, interceptor or concernts.

Who handles these concerns?
These types of concerns are best left to framework hosting the application, allowing developers to focus more on business logic.

AOP frameworks available
There are lots of frameworks available for AOP in java, and each one calls the concerns with differnt names, written within parenthesis:
  • AOPAlliance API (interceptor)
  • AspectJ (Aspect)
  • Spring AOP (Advice)
  • Spring-AspectJ combination (Aspect)
For AOPAlliance, click here.
AspectJ plugin for eclipse ide can be downloaded from here.
For spring we will see in tutorial continued. Since spring 2.0 AspectJ is the best AOP implementation, so its also combined in spring as told above.

Weaving or interjection
An AOP framework, such as spring AOP will interject or weave aspect code transparently into your domain model at runtime or compile time. This means that while we may have removed calls to the SecurityManager from the Business class, it will be still executed in AOP framework.
The beauty of this technique is that both the domain model (eg. our business code, say BankAccount) and its user or client such as Customer, both are unaware of the enhancement to the code.

What are cross-cutting concerns?

The Separation of Concerns principal states that a concern is any piece of interest or focus in a program. Think about it in terms of a layered architecture with the layers being UI, Business, Service and Data. Each one of these layers is its own concern. These layers are "horizontal".
The UI layer is only concerned with display and user interaction and not with database connectivity; as such, the data layer is not concerned with determining if a user is eligible for a car loan (business rules). When you design your code you usually break up these concerns into their own modules (classes, assemblies, etc).
Logging, security, error handling and caching are also concerns but where do they fit in to this layered architecture? The answer is everywhere. These concerns are "vertical" or "cross-cutting" or "orthogonal" which means they touch each layer. UI needs logging and error handling just as the other layers do too.

More terminology on AOP.

No comments:

Post a Comment