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".
