Cedric Beust wrote:
>
> Hi Myles,
>
> > A problem with CMP is that it is an all or nothing approach regarding
> > data access from the database. Ie. If you want to process a series of
> > single fields from a selection of CMP entity beans you have no choice
> > but to query for them and let the container load in all their data -
> > even though you are interested in only the one field per entity bean.
> >
> > The spec should introduce data containers (I suppose 'value objects')
> > that are views of a CMP entity bean. When defining a finder method,
> > rather than it always returning a single CMP bean or a collection of CMP
> > beans you can elect to return one of your data containers instead. The
> > data container will simply be a subset of the fields of your CMP entity
> > bean.
>
> I agree that this might be sometimes useful,
Actually this is quite often useful - as anyone who has to implement a fuzzy
search can tell you - the idea is to filter out as many of the instances as you
can based on the search parameters, then present the users with a list of
possibles to pick from. A list of PKs is not usually much use as a list of
possibles - the users usually needs some data to corroborate with, hence the
view.
> but you don't need to amend the
> specification to do that. What stops you from putting the intelligence
> regarding these "view fields" into a Stateless Session Bean that would issue
> the queries and pack the results into a value object before returning them
> to you?
A better approach than putting the intelligence into a SLSB is to put it into a
Home Method of the Entity Bean. That way all the code needed to access that
table is in the same EJB.
><SNIP>
Ian McCallion
Alexis Systems Limited
Romsey, UK
===========================================================================
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".
