Persistent Applications Toolkit

Choose font sizeNormal TextBigger TextHuge Text

PAT as a persistence aspect

Don't forget to read my personal, aspect blog:

Which AOP framework?

PAT uses JBossAOP as the aspect framework. I've did such choice mainly because at the time of developing AspectJ didn't have support for annotations. JBossAOP was driven by annotations from the same beginning (I think), so the choice was clear. Of course I knew differences between both.

The only disadvantage when developing such framework with JBossAOP is lack of binary introductions. JBossAOP is "Java compatible", so it means any aspectized source file must compile with <javac> or any Java compiler. But this causes the code look ugly when accessing introduced members (fields, methods). AspectJ is much better option in that case.

Orthogonality

Orthogonal in that particular case would mean: create any POJO based Java model, annotate every method that changes state of the system, annotate business objects, and that would be all.

Annotations - social view

Use of annotations in the case of persistence is in my opinion the best choice. It's much more better from the social view, than from technical one.
The user of PAT - a programmer - sees where the control flow of its application is changed - where the data is stored. It is more safe this way, than traditional regular-expression-pointcut-style. It is not exclusive way, though.
If one needs, one may define pointcuts using regular expression style (in a separate XML file) - no problem at all.

What about the aim of orthogonality?

Well, it almost worked out. Almost, because there are some requirements to the POJO model when designing it:
In general PAT will not work correctly when passing an object with indirect reference to a BO and not being BO itself - to a transaction. Whether it is rare case or not, it can be solved by just creating additional, short wrapper class.

SourceForge.net Logo

Revision: $Id: framework.gtml,v 1.4 2005/05/11 16:13:54 nthx Exp $
Generated with GTML