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