Hi Steve and Winston
I also agree with you. Entity beans are not alwasys solution to get the
data from the database.or update it. Excessive and unnecessary used may
result in quite a over head.
1. For eg if a report is to be printed say customers details which is read
only then instead or using finder methods and then using getter methods to
display the results I would prefer session bean which directly queries the
database and return me some collection to print it.
2. Also a report which involves complex joins is best to be done with
session bean.
3. Ejb are quite helpful in updating and creating records. which helps the
developer concentrate on business logic, front ends etc then writing the sql
queries. Transaction, security, concurrent access provided by entity beans
better then managed by developer.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Warm Regards
Ashwani Kalra
Sr. Member Dev. Staff
Aithent Technologies(P) Ltd.
email : [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Kenneth D. Litwak
Sent: Friday, June 22, 2001 4:25 AM
To: [EMAIL PROTECTED]
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".
===========================================================================
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".
