views:

189

answers:

3

Consider a set of DOAs with methods similar to this

public void addObject(Long sessionId, Long clientId, Dom obj){...}

Now every domain pojo (Dom) has a sessionId property and for every insert, update or delete on a domain object a sessionId must be passed with setSessionId(Long sessionId)so we can know who does what. But it seems that this cuts across the all the data access stuff we and I think AOP would be a good tool to insert the sessionId in either a @Before(JoinPoint) or @Around(ProceedingJoinPoint) advise. Is this actually feasible? The DAOs are mostly Hibernate based with a few Spring StoredProcedure.

+1  A: 

An interceptor around your DAO layer will have trouble accounting for transitive persistence, i.e. hibernate operations (save, delete, ...) cascading to associated entities. A Hibernate session interceptor could.

In any case, if your interceptor can somehow discover the current session id, this is possible to do either way.

meriton
+1  A: 

I don't see why you couldn't do this, I've actually done something similar (a little more complex) in the past, helped me not cross-refactor every class!

Have you thought of putting public void addObject(Long sessionId, Long clientId, Dom obj){...} in an father / upper level class? This method could delegate on each implementation..

Alejandro Tkachuk
+1  A: 

Your sessionId parameter seem to belong to an audit aspect. In Hibernate, this auditing aspect is typically implemented in an implementation of org.hibernate.Interceptor.

You can implement many methods that correspond to life-cycle event for your entities and queries. In your implementation, it is easy to get access to your current sessionId (it could use a ThreadLocal variable). Clear and clean, fast ;-)

This is probably simpler than doing it yourself with AOP, especially as you get callbacks from Hibernate for life-cycle events.

KLE