Francesco,
Your client should not be interacting with the entity beans i.e. remote,
directly since the performance overhead will be very large. Each
communication between the client and the entity will result in the the
creation of a separate transaction resulting in an expensive load and
potentially a store depending on the persistence management i.e. container
or bean, and the sophistication of your container cmp engine. What your
client should be provided with is a light weight JavaBean object(s) from a
session bean that reflects its specific data requirements. Any communication
between the client and the object would be local. This JavaBean object could
potential consist of a subset of fields from one or more entity beans and/or
some calculated data. An Entity Bean built for an enterprise wide system
could include large amounts of information that is not viewed by the many
different departmental or some other separation, clients. It would be very
inefficient to offer up an object which has so much information not needed
for the particular task at hand.
A customer looks different across departments i.e.accounts and marketing.
There will be some common overlap of basic fields like first name, last name
and so on but from there on things diverge some what. The marketing people
will probably be not much interested in the billing cycle fields and payment
history, just what your demographic data is or when you last made your last
purchase. This does not mean that I am advocating building an a single
customer entity bean which contains all these fields the point is that the
design decision for the entity bean and its potential ejb references or
dependent objects is hidden behind the session bean facade. The client is
insulated from changes in the entity bean layer just like the session bean
is relatively insulated from changes in the database structure through the
entity interface.
In your case your clients user object was a String which was derived from
one or more of your entity beans properties. The session bean is an
extension of your client application though providing a String object or
list of them through this interface is not the way I would build it unless
your building a primitive user interface.
regards,
William Louth
Borland/Inprise
www.inprise.com/appserver
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Francesco Marchioni
Sent: Tuesday, November 21, 2000 10:38 AM
To: [EMAIL PROTECTED]
Subject: Re: A Find method with a "pure " Collection
I solved the problem .
I've built a stateless Session bean that returns me the Collection
of Strings, taken from DB.
As a matter of fact when you use Entity beans whatever you
put in the Collection it will be converted to Stubs, so even if
you are allowed to return a Collection of Strings, when you
try to access that Collection on the client side you only
get the stubs and you cannot cast them to String!
Bye
Francesco
----- Original Message -----
From: francis pouatcha <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 21, 2000 4:29 PM
Subject: Re: A Find method with a "pure " Collection
> Hi,
>
> Is FindElements a method of the home or the remote interface? Can u send
> us your code.
>
> /Francis
>
> Francesco Marchioni wrote:
> >
> > Hi all,
> > I have the following problem: I've built a Find method which returns
> > a "pure" Collection of Strings: the Collection is built in this way:
> >
> > Collection FindElements() {
> > .........
> > Collection vec = new Vector();
> > vec.add(resultSet.getString(1));
> > vec.add(resultSet.getString(2));
> > .......
> > return vec;
> > }
> >
> > The problem is, when I try to browse the Collection on the client side,
> > I cannot cast back to String because the object inside the Collection
> > becomes a stub! at least that's what I got If I try to do a getClass()
> > with the elements of the Collection.
> > So it's not at all possible to return "pure" Collections, whose
> > elements are Strings, Integer ? do I need at any cost to return PK
objects?
> > thanks a lot
> > Francesco
> >
> >
===========================================================================
> > 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".
>
> --
> [EMAIL PROTECTED]
>
> MATHEMA Software GmbH
> N�gelsbachstra�e 25 b
> 91052 E r l a n g e n
> D e u t s c h l a n d
> Tel +49(0)9131/8903-0
> Fax +49(0)9131/8903-55
> http://www.mathema.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".
===========================================================================
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".
