see >>
> -----Original Message-----
> From: Anil Nair [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, June 16, 1999 11:24 AM
> To: [EMAIL PROTECTED]
> Subject: Re: using collection of beans as a bean ...
>
> I am no expert at this but let me take a stab at it.
>
> Say we have instantiated a bean representing the collection of say 'Item'
> beans and return a remote reference to the client. When the client asks
> for
> some info on the list of items, then is the assumption that the collection
> bean has a list of references of the item entities but it iterates over
> them
> on the server side and returns a list of data objects to the client ?
>
>> short answer is no. long answer is that you can do whatever
addresses your requirements. details are that you can copy the data to the
client in a structure of your choice. we use several styles but customized
collections are very useful. depending on how much iterating and what's
involved in the iteration, copy is good. you will of course be moving more
towards an optimistic model with this but you can ensure consistency in many
ways during the update transaction. one sort of item structure is covered
elsewhere on this thread.
> Here is how I understand it. An ItemCollection bean helps us to avoid
> activating all the individual Item beans when you do a find.
>
>> more correctly, it obviates the need. note that "it" may or may
not be an ejb.
> To do what you
> have described above, you just need a session bean.
>
>> i got lost in the thread so i don't see what's described.
however, a general statement i can make is that session bean is very rarely
needed and is, imo, overprescribed and misunderstood.
> You dont need a
> collection bean. The session bean wraps the Item entity beans' finders can
> iterate through the collection on the server side.
>
>> you're making many assumptions here, the most important of which
is that the session bean is closer to the entity than the client is.
> If you follow the
> Weblogic/Anne Thomas recommended model of wrapping all entity bean access
> with session beans, you have these session beans already.
>
>> understanding the session-wraps-entity model is important. once
you understand it, challenge it and determine when it applies to your
problem. a good exercise is to solve a small problem with a
session-wraps-entity bean structure. now refactor your solution to be 100%
entity-bean. now refactor to be 100% session-bean. edge conditions are
usually enlightening and you'll definitely learn from the exercise.
> My understanding of the "collection of beans as a bean" model as discussed
> by the Valto folks/Jim Frentress etc is to define an ItemCollection bean
> which would load all the information requested by the client from storage
> when the ItemCollection bean is created.
>
>> the structure may or may not be a bean. what you load is totally
up to you. the important thing is that you have the option to load as much
or as little as you want (rows and columns).
> The primary key for this
> CollectionBean would be the "where clause"/restriction which identifies
> the
> collection.
>
>> no, there is no primary key for this collection. the members of
the collection may have keys, the collection (structure) may simply be an
attribute on some other bean, or something else.
> If a second user needs an ItemCollection with the same "where
> clause"/restriction then the collection is cached (subject to the number
> of
> beans in cache/idle time out etc).
>
>> not applicable to our structure, not even necessary.
> These are read only beans.
>
>> nope. totally read/write.
> What I dont
> understand about this model is how an ItemCollection gets refreshed when a
> new Item bean is created or deleted.
>
>> this is application dependent and you have many possibilities
here. it's difficult to talk specifics until we pick a definition of "Item".
there are many types and requirements and the pattern to apply depends on
the type.
> If the information required by the second client is a different set of
> Item
> fields then you have two choices. 1. Define an ItemCollection2 which would
> load the set of fields required by the second client. or 2. Define
> ItemCollection to load the superset of Item fields required by client 1
> and
> client 2. And have two methods which return the different set of fields.
>
>> present a specific example and we'll address it. there is no
particular problem here.
> To me, the issue is not whether you iterate through all the Item beans
> that
> satisfy a particular criteria in the client or the server. In either case,
> it is a big expense.
>
>> not necessarily and it's never expensive in our architecture. we
use several patterns applied to different problem sets and we have none of
the typical distributed problems.
> You shouldn't have to instantiate/activate all those
> Item beans and load all the detail information associated with each Item
> bean just to get a summary set of fields for the list of Items that match
> your search criteria.
>
>> you're correct and with our architecture we never do.
> The folks who recommend "session bean" wrappers for
> every entity bean suggest that you bypass the entity beans and fire SQL
> using JDBC against the database to solve the issue.
>
>> note that entity, even CMP beans can fire SQL just as a session
bean can.
> Anil
>
> ==========================================================================
> =
> 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".
