Hi Ken,
Thanks for the reply. I understand from the message, that your
approach would be to use session beans to do search queries for accessing
data, instead of using finder methods. Then load the appropriate CMP bean,
if necessary to interact/update the data that one or more clients deal with
to maintain a persistent state. Please let me know, if I interpreted your
design correctly.
If, I had interpreted it correctly, I feel that the CMP bean is
primarily used only for data updation. Where most of the complex data
retrieval logic is being implemented on the session bean. Wouldn't it be
more better to implement the data updation logic in a normal java class.
This way we could avoid all the data marshalling/unmarshalling over- heads
that's inherent with a CMP bean.
Thanks,
Winston.
----- Original Message -----
From: "Kenneth D. Litwak" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 6:55 PM
Subject: Re: Are Entity Beans(CMP/BMP) really necessary???
> I don't know that entity beans are necessary. On the other hand, I
do
> think that having an object whose persistent state is managed for me by
the
> container (in either BMP or CMP) is desireable. At the same time, I think
that
> there are lots of things one can do with entity beans which make them
> aperformance problem: finder methods which return masses of data; 2.
Ussing
> them for single database access operations (I got the data one time and
need it
> exactly one time); 3. Allwoing clients direct access to entity beans
>
> IMHO, the way to use an entity bean is generally would be the
following
> scenario:
> 1. Session bean returns one or more rows/objects from a database
> 2. User selects a row that he/she cares about, in an application
which
> geneally would have the user interacting with the row/object multiple
times.
> 3. Session facade finds the entity bean's orw/object and uses the
> entity bean.
> This makes for a less brittle architecture, and uses entity beans
in a
> conservative way.
>
> Ken Litwak
> >
> >Hello All,
> > After trying to build a robust EJB model that needs to
scale
> >and perform well. I have pretty much come to the conclusion of avoiding
any
> >use of Entity Beans(CMP/BMP) at all in the design.
> > In my perspective, I see Entity Beans as nothing but a
> >"replication" of the underlying data in an OO fashion. Though, there is
> >nothing wrong with this, Entity Beans seems to come with a lot of
overhead.
> > Yes, a CMP bean gives added functionality of
> >accessing/updating the underlying data without having to write any code
from
> >the developer perspective. But, this seems to come with a major
performance
> >degradation. Its completly dependant on how well the container is
> >implemented by the vendor. Ofcourse, its not possible to write any
complex
> >data-retrieval logic on a CMP. Defining a coarse-grained bean seems to be
> >very difficult on a CMP bean. I'm not sure, if a CMP bean can handle any
> >underlying data thats NOT relational in nature. Dont know, if a CMP bean
> >could ever be implemented, which doesnt care of the underlying data
> >format(XML, flat file's, RDBMS) and still be portable. I'm not sure if
the
> >new EJB 2.0 spec, defining EJB QL and Local Interfaces would really
> >alleviate any of these issues.
> > When considering BMP's, it does give better control
over
> >the underlying data to the developer. But, it still comes with a lot of
> >overhead. Some, J2EE design patterns(DAO, ValueObjects, Value List)
suggests
> >different ways to avoid these overheads or pitfalls(like network
chattiness,
> >seperation of Data access logic, etc.). But, somehow it seems to me that
the
> >Entity Bean itself is inherently flawed and using a host of design
patterns
> >to overcome this seems like a futile excercise.
> > For now, most of my design seems to be in this fashion. I
> >have defined DAO's which has the logic to access underlying data. The
DAO's
> >returns a DataModel representing the data when called upon. These
DataModels
> >that contains the data is wrapped by a SFSB. The SFSB implements some
> >business methods and iterating methods which would use the DataModel
> >containing the data. Ofcourse, we could use the ValueObject pattern on
top
> >of this to send minimal data needed by the client.
> > I feel this above design is lot more coarse-grained
,gives
> >better control over the underlying data, transactional and comes with
less
> >overhead.
> > I might be wrong in my above assertions. Do correct me,
> >before u shoot me down. Is there any potential issue, I might have
> >overlooked in trying to avoid Entity Beans completly from my design??? If
> >this question has already been discussed in this list, please do point me
to
> >the appropriate thread.
> >Thanks,
> >Winston.
> >
>
>===========================================================================
> >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".
