Q:

AOP: basic ideas - keep objects simple? 

I work with Spring Framework 3.0.5 and Id like to understand the basic principals of Spring. One of it is AOP. 
One basic idea of the spring framework is to keep the objects itself simple and to have clear code. 
DI follows this basic idea. It provides clear code and the objects itself can be very simple. The dont have to look up their dependencys.
Now what about AOP: I mean, code is for sure clearer with AOP, but does AOP also have the basic idea of keeping the objects as simple as possible? Im not sure of that, thats why Id like to know some other opinions :-)
Thanks in advance!

A:

The main motivation for AOP is to use it for so called cross-cutting concerns, as in functionality you need to provide in basically all parts of your application, usually these include:

logging
authentication
auditing
transactionality. 

AOP allows you to extract these functionalities into separate classes and just mark your classes which need these.
Watch this excellent video to get the main idea. To answer your question, yes, it will help a lot to keep your classes clean, because they will only take care about their own functionality and don't have to provide boilerplate code over and over again.

A:

Take the following code snippets as an example. The easy way:
@PersistenceContext
private EntityManager em;

@Transactional
public void save(Object obj) {
    em.persist(obj);
}

The traditional way (you can manage transactions using EntityManager interface, but that is not the point):
@PersistenceContext
private EntityManager em;

@Resource
private AbstractPlatformTransactionManager transactionManager;

public void save(final Object obj) {
    new TransactionTemplate(transactionManager).execute(new TransactionCallbackWithoutResult() {
        @Override
        protected void doInTransactionWithoutResult(TransactionStatus status)
        {
            em.persist(obj);
        }
    });
}

What does it have to do with AOP? Transaction management is one of the most widely used examples of AOP and Spring is not an exception. The former code snippet uses @Transactional annotation to apply transaction demarcation using aspect, while the latter manages transactions manually. See the benefit?
The key thing: use aspects for cross-cutting concerns like logging, profiling, etc. Don't build your business logic in aspects. This way your beans remain clear while irrelevant code from business perspective is hidden in the aspect.
Also AOP allows you to do all sorts of sophisticated stuff with ease. Take for instance HTTP session handling - with session bean scope and AOP proxying you can access session without even realizing it.
To summarize - it is great tool when used for the right job.

