<vendor> In GemStone/J you can implement your Car and Manufacturer abstractions as plain old java objects (i.e., domain objects) with direct pointer referencs between them, and persist them using GemStone's object persistence capabilities (aka PCA). Furthermore, you can give your JSPs direct in-VM access to these persistent domain objects, so you don't have to introduce extra classes to distribute domain object state. And for scalability you can load-balance across an array of such VMs and use our distributed http session tracking feature, which leverages PCA, to move conversational state between the VMs. IMHO this is the most efficient architecture for binding domain object state into dynamically-generated HTML - O/R mapping and object state distribution introduce a lot of extra complexity into your system responses. At GemStone we're undertaking studies to quantify the effects of these architectural decisions on application performance and scalability. Of course you can use GemStone/J to implement O/R mapped entity beans if it is important to you - but you don't have to. We give you other options. It may be blasphemy and heresy on this list, but if I had to build a system with a JSP UI for a business today, for maximum efficiency I would use an undistributed architecture and object persistence for that purpose. </vendor> Best Regards, Randy Stafford Senior Architect GemStone Professional Services > -----Original Message----- > From: Robert Kr�ger [SMTP:[EMAIL PROTECTED]] > Sent: Sunday, February 20, 2000 3:13 AM > To: [EMAIL PROTECTED] > Subject: Re: trying to come up with a design pattern to solve a > common J2EE problem > > At 18:10 19.02.00 , you wrote: > ><snip> > > > > This must be a common enough usecase in J2EE programming that > someone > > must > >have thought of this before, can anyone suggest a clean solution to this > >problem? > > > > > >thanks in advance, > > > >Floyd > > you summed it up very nicely and there simply is no way of either avoiding > the database calls or the SQL join but what's wrong with that? entity > beans > are a great tool for manipulating your datamodel and for RAD but when it > comes to presenting different views on the data (i.e. results of queries) > efficiently in most cases the best thing is to just write that sql. > encapsulate the query and the result in an object oriented way and make it > part of your facade. IMHO that's the most straight forward way to do it. I > try to avoid having to write sql and jdbc code where I can but you have to > be careful in deciding whether you're actually shooting yourself in the > foot by trying to avoid them at any cost. I have been using entity beans > (especially cmp) extensively in the past few months and I can now observe > the tendency to go back to the basics where it makes sense. why just use a > relational database as a dumb data bucket and not use its features?. > > just my 2c > > robert > > > (-) Robert Kr�ger > (-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH > (-) Br�der-Knau�-Str. 79 - 64285 Darmstadt, > (-) Tel: 06151 665401, Fax: 06151 665373 > (-) [EMAIL PROTECTED], www.signal7.de > > ========================================================================== > = > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
