RE: [Springframework-developer] Re: [Springframework-user] Delayed association of transaction with session

[James C. <jim...@do...>]

Good idea Erwin. I'll give that a try.

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Erwin Vervaet
> Sent: Thursday, May 05, 2005 10:29 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: [Springframework-user]
> Delayed association of transaction with session
>=20
> One way to make it more elegant is to use an object initialisation
> callback
> interface. That way the controllers can pass this initialisation =
strategy
> into the service layer, which will call it to initialize any objects
> ("excercizing" the lazy associations) it returns back to the =
controller.
> As
> a result you have a situation where
>=20
> 1) the controllers "define" (by implementing the initialisation =
callback
> interface, mostly using an anonymous inner class) how to initialize =
the
> objects retreived from the service layer, which can be specific to =
that
> controller and its views
>=20
> 2) no explosion of methods on the service layer to support all =
possible
> usage scenarios by the controllers
>=20
> 3) for optimisation you still have the option of defining a =
specialized
> service method which is backed by a specialized query
>=20
> Erwin Vervaet
> erw...@er...
> ----- Original Message -----
> From: "James Cook" <jim...@do...>
> To: <spr...@li...>
> Sent: Thursday, May 05, 2005 3:11 PM
> Subject: RE: [Springframework-developer] Re: [Springframework-user]
> Delayed
> association of transaction with session
>=20
>=20
> That's the thread where I described a service layer approach that we =
began
> using when we ditched OSIV. We give our web-tier a service layer to
> interact
> with that defines a transactional boundary.
>=20
> It worked very well for us, except for the problem that Ugo Cei =
brought up
> regarding the ugliness of pre-loading lazy-loaded collections. Not =
really
> a
> problem, but not so elegant.
>=20
> jim
>=20
> > -----Original Message-----
> > > There are other workarounds that may be jammed in, but the ones I =
can
> > > think
> > > up are not exactly elegant. Perhaps this is simply a case of =
developer
> > > beware; a known side-effect to using the OSIV approach to web
> > development.
> > > I'd appreciate any advice on whether the framework can be coerced =
to
> > > eliminate one of the remaining flaws in this pattern.
> >
> > Also take a look at the following discussion, which details more of =
the
> > issues of OSIV:
> >
> >
> =
http://www.newsarch.com/archive/mailinglist/comp/java/springframework/use=
r
> > /msg03641.html
> >
> > Erwin
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great =
events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great =
events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer