Chip Wilson schrieb:
>
> Michael Schuerig wrote:
>
> > Jon Ferguson schrieb:
> >
> > > 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.
> >
> > This is roughly how we're doing it, too. One difference is that we're
> > using EJBObjects instead of primary keys. Is there any reason to prefer
> > primary keys?
>
> There is assuming that the client is not interested in every entity represented
> by the collection of light-weight proxies. If the client is only interested in a
> subset, for example one, then you save alot of server procesing by not loading
> all those entities. This also assumes that you are not creating your
> light-weight proxies by enumerating entities, but are instead performing a
> database query that selects out just the data required by the client to identify
> the entity of interest, plus the PK of each entity.
We are using finder methods, thus we have to enumerate entities anyway.
For general queries, using primary keys would be an optimization. Thanks
for bringing it to my attention.
Michael
===========================================================================
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".
