Yes, it occurred to me also that having the domain
classes doing persistence usually isn't a good idea.
However, using something like OJB or Hibernate should
eliminate the need for a DAO layer in the traditional
sense. Myself, I have been using a Service Layer
approach that I'm fairly happy with most of the time.
The Service Layer approach also plays very well with
something like Spring, as the Service classes end up
being just the right place to apply "aspects" for
transactions and session handling.
--Chris
--- James Carman <james@xxxxxxxxxxxxxxxxxxxx> wrote:
> 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
> >>
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
|