There is something you should consider here. Maybe having different "type"
of classes all doing the same thing (persistence manipulation) isn't such a
good approach. Usually, whenever a class needs to manipulate (create, read,
update, or delete) a "domain" or "business" object's persistence, it uses a
DAO object. I would introduce a DAO "layer" here and that should solve your
problem with having to use AOP to "introduce" fields/methods into your
classes that your IDE won't know about.
-----Original Message-----
From: Matt Avery [mailto:mavery@xxxxxxxxxxxxxxx]
Sent: Tuesday, May 11, 2004 10:36 AM
To: users@xxxxxxxxxx
Subject: Re: [cinjug-users] Looking for AOP framework
Chris,
I'm not using AspectJ yet, but I'm considering using it for the project
I'm working on. I'm doing exactly the same thing you described with
Hibernate only I'm using OJB.
The version of OJB I'm using has a bug in it, so I wrote an object to
work around the bug called "BrokerSupport" (think
PropertyChangeSupport). Every object that needs to access the database
has this code in it:
protected BrokerSupport fieldBrokerSupport;
protected PersistenceBroker getBroker()
{
return getBrokerSupport().getBroker();
}
protected BrokerSupport getBrokerSupport()
{
if (fieldBrokerSupport == null)
{
fieldBrokerSupport = new BrokerSupport( );
}
return fieldBrokerSupport;
}
protected void closeBroker()
{
getBrokerSupport().closeBroker();
}
Since the business objects extend different superclasses, I can't move
this code to a single abstract superclass. So much for "once and only
once".
I was thinking of making a "BrokerSupportAspect" that would intercept
the getBroker() and closeBroker() methods in those objects. My question
is, what is the best practice for using aspects in a situation like
this? Do I just add a blank implementation of getBroker() and
closeBroker() to each class and then use the aspect to fill in the guts
at runtime, or is there some other technique I should use?
Thanks,
Chris Nelson wrote:
> Mike,
>
> It's important to consider what you are doing when
> choosing an AOP implementation. Are you wanting to
> develop your own custom aspects or merely use other
> prebuilt aspects to solve a given problem? How
> dynamic do you need your aspects to be? I've use
> AspectJ a bit, and am using it now on an project. For
> applying custom developed aspects to a largish
> codebase I find it to be very productive. I find the
> AspectJ language to be quite expressive, and by using
> the Eclipse plugin it is easy to see what your aspects
> are going to affect (what your pointcuts actually pick
> out).
>
> However, we are also considering using Spring so we
> can use its' ready made aspects for transaction
> handling and opening/closing of the Hibernate session.
> We could, of course, write our own AspectJ aspects to
> deal with these issues, but the fact that Spring has
> premade aspects to do this is attractive.
>
> A couple other issues to think about when choosing AOP
> implementations are:
>
> 1) Dynamic/Compile time:
>
> AspectJ applies aspects to a code base by using a
> compiler/weaver at compile time. This means your
> classes are just plain old Java code and only require
> a small library at run time. However, if you want to
> add/remove aspects you need to recompile, no different
> than if you were changing other code.
>
> Other AOP implementations(AspectWerkz, JBoss AOP)
> apply aspects at runtime by modifying the bytecode of
> your classes at runtime. This means, of course,
> aspects can be added/removed at runtime. The price
> for this is having to use a custom classloader, and
> being willing to trust your AOP modifying your
> classes' bytecodes at runtime "on the fly". Though
> this made me squeamish initially, the fact that so
> many implementations are doing this successfully has
> made me less so over time.
>
> 2) Language extension?
>
> AspectJ is an actual language extension vs other
> implementations that use another format (XML config
> files for instance) to specify how to apply aspects.
>
> Well, I've already rambled enough for now. Great to
> see someone else bring up AOP on the Cinjug list! As
> you can see, it's kind of a pet interest of mine.
>
> Later,
>
> Chris
>
> --- "Witt, Mike (OH35)" <mike.witt@xxxxxxxxxxxxx>
> wrote:
>
>>I'm planning to spend some time experimenting with
>>AOP. I'm wondering if a
>>de facto AOP framwork is emerging. Right now, I'm
>>looking at AspectJ and
>>Spring, there are probably others as well. So, I'm
>>looking for an opinion
>>on which framework to use based on:
>>
>>- What's the standard
>>- Which one is the most newbie friendly - available
>>documentation and
>>tutorials
>>- Eclipse plug-in support
>>- Hibernate support
>>- Most active development community
>>
>>Thanks for the suggestions.
>>
>>Mike Witt
>>
>>
>>
>>---------
>>You may unsubscribe from this mailing list
>>by sending a blank email addressed to:
>>users-unsubscribe@xxxxxxxxxx
>>
>>--
>>Find additional help by sending a blank email
>>addressed to:
>>users-help@xxxxxxxxxx
>>
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs
> http://hotjobs.sweepstakes.yahoo.com/careermakeover
>
> ---------
> You may unsubscribe from this mailing list
> by sending a blank email addressed to:
> users-unsubscribe@xxxxxxxxxx
>
> --
> Find additional help by sending a blank email
> addressed to:
> users-help@xxxxxxxxxx
>
>
>
--
Matthew Avery
Senior Developer
(513) 470-5316
http://www.einnovation.com/
---------
You may unsubscribe from this mailing list
by sending a blank email addressed to:
users-unsubscribe@xxxxxxxxxx
--
Find additional help by sending a blank email
addressed to:
users-help@xxxxxxxxxx
|