As always, imho, fwiw and other suchlike disclaimers ....
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 --
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.
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.
> 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.
Hope this isn't too far off the mark ... I'm learning from this
mailing list as I go. Peace,
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".
