What about the possibility of using read-only entities for caching lookups?
This is assuming the container can be optimized to remove any overhead due
to the fact that the bean has been specified as read-only.
>From: Ashwani Kalra <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: FW: Are Entity Beans(CMP/BMP) really necessary???
>Date: Fri, 22 Jun 2001 10:04:45 +0530
>
>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".
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
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".
