great to see you here Ihab, see below...
> -----Original Message-----
> From: Ihab A Awad (CBC) [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, May 16, 1999 8:29 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Real advantage of session bean wrappers?
>
> As always, imho, fwiw and other suchlike disclaimers ....
[Frentress, James] i just love people with a sense of humor ;)
> Anne Thomas writes:
> > <snip>
> > In many applications the view uses multiple model instances. If the
> > client works directly with the entity beans, then the client has to
> > get a reference for each entity bean instance. If you wrap the
> > entities with a session bean, then the client only needs one
> > reference. The session bean manages all of the references to the
> > entity instances. This approach definitely reduces resource
> > requirements (one OUT reference versus many OUT references).
>
> Here's the fundamental distinction being made --
[Frentress, James] more correctly, yours is a somewhat exaggerated
example designed to magnify the fundamental issue.
> Client-side collections: The client code contains a java.util.Vector
> (say) which contains 5000 remote references to 5000 Employee objects
> on the server side.
>
> Server-side collections: The client code contains a remote reference
> to a java.util.Vector (say) on the server side, which in turn
> contains 5000 local references to 5000 Employee objects.
>
> This is a design pattern issue ... the 2nd approach is clearly better
> for remote programming because it reduces network traffic.
[Frentress, James] it's better for some things, not as good for
others. Richard Monson-Haefel started a thread some time ago where he
engaged the list by laying bare his strife on the topic.
> NOW -> we run into a language limitation in statically compiled
> languages like Java. Say you have a server-side collection of Employee
> objects. If this were Smalltalk, your client code might be able to do
> something like the following (I don't know Smalltalk syntax -- my
> ignorance -- but please consider the semantics) --
>
> Collection c = /* remote reference to collection on server side */
>
> c.applyToAll("if (item.getName() == "Anne") item.setSalary(500000);");
>
> The problem is, Java doesn't let you do this. So you need to wrap such
> common operations as methods in your server-side collections.
[Frentress, James] untrue. good design, creative reflection, and a
number of other methods address this very well. i feel sorry for Anne, she
needs to adjust her income sources to optimize her tax situation ;).
> > You could implement the controller function using an entity bean
> > (using a session ID as the primary key). This approach has some
> > significant advantages -- the session data could be persistent, so
> > you could easily recover a lost session.
>
> Voila ... so persistence of your collections is an orthogonal issue
> and depends solely on how long and under what circumstances you want
> them to hang out. So, a collection of "all the employees a particular
> user is interested in" might have session scope, while a pre-built
> collection of "all the salaried employees in the company" could be
> made persistent so that it can be reused by all clients.
[Frentress, James] see Valto's collection stuff for one of many
possible solutions to this. btw: i don't use Valto (yet anyway) but it's
worth a perusal.
> Hope this isn't too far off the mark ... I'm learning from this
> mailing list as I go. Peace,
[Frentress, James] he who isn't learning is dead (someone probably
said it). war (i like balance in life ;)
> Ihab
>
> --
> Ihab A Awad <[EMAIL PROTECTED]>
> Computational Biology Centers, Academic Health Center,
> University of Minnesota. http://www.cbc.umn.edu/~ihab/
>
> ==========================================================================
> =
> 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".
