Thomas, Great! I wasn't aware of retrieveReference, retrieveAllReferences. That makes option 3 much more appealing. It's much cleaner than what I was thinking of -- having the controller call get methods on the OJB objects, to trigger the side effect of loading the proxies! (Ug!)
Thanks! Steve Molitor -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 4:01 PM To: OJB Users List Subject: Re: OJB in a model 2 servlet/jsp architecture + proxies Hi all, I see exactly the same option Stephen mentiones: 1.) have additional VOs 2.) use OJB proxies from within your jsp pages by using the remote capabilities of OJB proxies. 3.) use explicit loading from your controller (struts action or servlet) 1.) requires stupid additional coding. 2.) may undermine the layering of your application a bit. 3.) needs additional coding, but gives you full control. The OJB PersistenceBroker provides methods to support explicit loading of references (retrieveReference("attribute") and retrieveAllReferences()). IMO 3. can be a very good compromise. cheers, Thomas Molitor, Stephen wrote: > Frank, > > I've encountered the same issue (with a home-brew persistence framework; I'm > new to OJB). I guess you have two choices: > > 1. Translate persistent OJB objects to / from value objects. So you need > value object assembler code to do the translation, and an extra class for > every OJB persistent object. I.e. Customer OJB object, and CustomerVo dumb > value object. Yuck! > > 2. Let the JSP page make database calls. You could use a Servlet Filter to > configure, and takedown the OJB stuff, and have it open the database in read > only mode. Plus the filter could catch any concurrency exceptions (i.e. > someone has deleted the lazy loaded object or its parent), and forward to an > appropriate error page. I tried this in a prototype last week. It seemed > to keep the application code really simple; no unecessary layers. But I > have to admit I'm a little nervous about it. On the other hand, I hate the > extra complexity of all the little value object classes, that essentially > duplicate the OJB beans, and the schelping code ('value object assembler' > code). > > I suppose another option is to have your servlet (or Struts action) > explicitly trigger loads of any dependent proxies. Seems kind of brittle > though, because a change to the repository.xml could force a change in your > servlet to trigger more proxy loads. So I really don't like this option. > > Let me know what you come up with; I'm struggling with the same issue. > > Steve Molitor > > > > ORIGINAL MESSAGE: > From: Frank Renaers <[EMAIL PROTECTED]> > Subject: OJB in a model 2 servlet/jsp architecture + proxies > Date: Fri, 11 Oct 2002 09:43:38 +0200 > Content-Type: text/plain; > charset="ISO-8859-1" > > Hi, > > I am using a model 2 jsp/servlet architecture. > Each business service (Facade Pattern) returns one or more business objects. > (i.e. ojb beans). > I am using here the Value Object Assembler Pattern to return the ojb beans. > Remark : one of the advantages of Jakarta OJB (compared with entity beans) > is that you don't have to create special value objects. > My view (jsp) will read the necessary values from the ojb beans. > But suppose that the jsp accesses a proxy collection which is not yet > materialized. > This will result in a database call from within my jsp's !!!!! > Does someone know how to solve this problem ??? > Which pattern are you using to return 'value objects' to the jsp's ??? > > Thanks, > > Frank Renaers > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
