Hi Tom,
I think the design would be different dependent on the client. Eg. with a
client application you might want a class implementing the Collection
interface that internally does the lookups of 'light-weight' proxies (which
might contain a primary key + label - in many cases the label shown to the
user may be part of the pk). The Collection is serializable and originally
populated server side with the results of you're specific query. The
results are that the client can view a simple list of labels but when they
select one and request more information the 'light-weight' proxy first
populates itself with the full class then returns the desired info. Thus
you want to look at the proxy pattern. I seem to remember that Rickard
�berg had a smart proxy object on his site a number of months ago. If you
have a web interface and can't use Collections directly I'd suggest the same
thing from within a servlet. You can store the thing in the session. Or it
could be contained inside a SessionBean which could then talk with the
servlet.
The difficulty probably lies with how you design your bean/database mapping.
If my bean maps to a simple row in a database table then there is no space
savings on the server. The finder method first creates the beans on the
server then returns you an enumeration which you can use to populate your
collection before its sent to your client. The savings are that you don't
send much to the client in the first place, and you minimise the number of
remote calls you make subsequently. If on the other hand the bean is more
complex and across more than one table you could model it as a couplet. The
first bean could be a 'handle' to the second, and contain only enough
information to provide a lookup and label. Should you be collocating a
web-server & application-server on the same machine (I know, bad news),
these beans can virtually be your proxies and manipulated from within a
SessionBean. If on the other hand you have a remote application You can
send the above collection across the wire. The benefits are the same as
before but with smaller server memory load, (at the expense of an extra bean
lookup when you really want the info).
Ok - now I know all you clever people are going to tell me the problems with
this approach - great. Learning is part of the fun.
All the best,
Jon
Jon Ferguson PhD.
Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
"The art of living is to experience more and to want less."
-----Original Message-----
From: Tom Jordan [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 29, 1999 8:29 AM
To: [EMAIL PROTECTED]
Subject: Re: Design Pattern - was Returning Collections - Serializing vs
RemoteObject?
Jon,
The senario you describe is exactly the problem I need to solve. Are there
any design patterns for this? Seems like a very common problem.
Thanks.
Tom.
>From: Jon Ferguson <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Returning Collections - Serializing vs RemoteObject?
>Date: Mon, 25 Oct 1999 07:57:00 -0500
>
>Good question Tom.
>
>This kind of scenario happens alot. It really boils down to what the
>intention is at the client. I've tried both. As Jim Richards said - for
>remote clients using the returned enumeration requires a network call each
>time you iterate. Downside with returning a whole collection is the
>serialisation time etc.
>
>You may only want to show a list of object names in a scrolling list
>somewhere. Then allow the user to pick from the list. Eg. you want a very
>little information about a lot of objects and possibly a lot of information
>about one or two objects. Assuming you can cache information on your
>client, I'd be tempted to send just the primary keys and a pertinent
>strings
>wrapped in a collection, then do a findByPrimaryKey when the particular
>object from the list is selected.
>
>Cheers,
>Jon
>
>Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
>"The art of living is to experience more and to want less."
>
>
>
>-----Original Message-----
>From: Tom Jordan [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, October 24, 1999 7:37 PM
>To: [EMAIL PROTECTED]
>Subject: Returning Collections - Serializing vs RemoteObject?
>
>
>Hi
>
>I often need to iterate through a Collection and was wondering if its
>better
>to return the collection the client, which is by default serializable or
>would it make more sense to wrap the collection such that you can iterate
>through it remotely? I would like to know what experiences people have had
>with either or another approach that might be preferable. Any pros or cons
>to either approach?
>
>Along the same lines finder methods of entity beans return enumerations. I
>have read in the archieves of this list that holding that storing this enum
>has a negative impact on the server in terms of resource consumption. Is
>this true? In a situation where a finder method return 50-100 records, I
>might not want to send all of them to the client. Would it not be
>reasonable to store the enum in a session object, get the block of records
>you want and return those as a small collection (remotely or serializing
>what ever is the recommendation from above). Is there a better way to
>handle this?
>
>Thanks in advance.
>Regards
>Tom
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>
>===========================================================================
>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".
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
===========================================================================
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".
