[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] AspectJ and metadata
|
hi adrian,
>So my question for the group is: do you prefer to separate out these
>sorts of concerns with AspectJ, or unify them with XDoclet or >metadata?
i guess there is a simple and and a more verbose aswer to this.
a) metadata for for example hibernate is certainly an aspect
of a class and should therefore be separated into its own
physical module so that the normal flow can be easily read.
b) so the question is not so much IF but WHEN. at which stage
of your development process should you start to move metadata
(be it xdoclet or annotations) into its own file?
just to give you an example: our product (100kloc+ java and
120kloc+ xml) started by using xdoclet for hibernate.
this was very convinient at the beginning as we where just
exploring features of what we where building. also we
where new to hibernate. so changes to accessors where easily
handled by xdoclet.
now after almost 9 month and 100kloc java xdoclet was starting
to get into our way. we had classes of 800 lines java. where
200 were simple accessors, 300 lines where xdoclet and another
300 where some sort of business-logic.
so the most obvious way to cut down the size and make the class
maintainable again was to move the persistence aspect into its
own location (of course we split up the structure into its own
base class that was easily reused by other modules). this was
also easy as class(es) have become more stable and their
underlying persistence schemas as well. this of course was
also a natural effect as more and more clients were depending
on the class as well as on the schema.
so what would really help is a sort of refactoring tool that would
be able to move annotations from a .java file into a .aj file
using "declare annotation".
ciao robertj
Adrian Powell wrote:
In the "Eclipse AspectJ" book, the integration between Hibernate and
AspectJ came up several times, both in the initial example and then
towards the end of the book where it is refactored to use Spring. The
example raises an interesting design philosophy question which I've been
trying to hash out with collegues, but we haven't come up with any
clinching arguments.
The problem is this: in our applications, we have been using XDoclet to
add Hibernate information into our Java source files. The goal is
ostensibly to centralize the functions of a class into one location so
that its functionality is clear and easier to maintain. On the other
hand, the AspectJ example goes the opposite direction and tries to
separate out all of the Hibernate functionality. In the XDoclet
solution, we have a single .java file and an ant script which will build
the .hbm.xml files. In the AspectJ solution, we have a .java file, a
.aj file, and a hand-coded .hbm.xml file. I recognize that the AspectJ
example is just that, an example, but it does have some interesting
advantages. With metadata entering Java 5, I think the issue of how to
decompose and modularize a solution will continue to gain attention.
cheers,
-adrian.
--
Adrian Powell
Centre for IBM e-Business Innovation :: Vancouver
apowell@xxxxxxxxxx / 604-297-3194