Muly,
I don't think you can categorically say BMP is bad/slow. Tools like Cocobase
will generate efficient third tier interactions with regard to finders to
address the issue you point out below.
My view:
Entity Beans to add remote component overhead, but this isn't too bad if
entity beans represent a coarse grained component with sub-objects which are
non-bean.
CMP is a great idea, but the spec needs work so that implementations across
vendors are more even/portable (e.g. relationships to non-bean sub objects
need to be standardized, issue with finders need to be addressed...). As I
understand it, these issues are to be addressed by the 2.0 specification.
In the mean time session beans directly to persistently mapped objects, or
session beans to BMP entity beans are decent solutions. A tool that helps
with the OR mapping in either case is a big help.
-Chris
----------------------------------------------------------------------
Chris Raber, Director Professional Services, GemStone Systems Inc.
100 West Big Beaver, Suite 200, Troy, MI 48084
phone: (248)-680-6691, fax: (248)-680-6689,
email: [EMAIL PROTECTED]
web: http://www.gemstone.com/
----------------------------------------------------------------------
> -----Original Message-----
> From: Muly Oved [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, September 30, 1999 10:58 AM
> To: [EMAIL PROTECTED]
> Subject: Doubts about Entity beans, Should we use them?
>
> Hi
>
> For design a non-trivial distributed database application,
> to be implemented in Application server.
>
> Here some guidelines and ideas I picked during my searching, I maybe wrong
> :)
>
> * Don't expose entity beans to the clients:
> It is recommended that the client will talk with session beans and the
> session beans will talk with the entity beans.
>
> This way the client request for operation form the session beans and the
> session bean do all the work, by access to multiple entity beans and other
> session beans and work as a facade,
> hiding from the client the server object schema complexity
> and collect the operations a client need to do to one operation
> those avoiding network traffic.
>
> * Bean managed persistence is BAD:
> Also there is a clear and easy framework how to write the code for BMP.
> It is BAD to use it if performance is important.
> Using BMP will be VERY inefficient and will generate many small SQL
> operations.
>
> If you need operation like
> SELECT FNAME,LNAME FROM EMP
>
> BMP will generate:
> SELECT PKEY FROM EMP
> And then for every record in the table
> SELECT FNAME,LNAME,ADDRESS,... FROM EMP WHERE PKEY=?
>
> * Component managed persistence is problematic:
> Also theoretically the container can do some optimization to overcome
> the BMP problem, there still a problems There is no standard how to
> specify mapping to the component (Fields, and Find code)
> Most of the implementation are trivial and does not allow complex mapping
> between beans and database.
> Those limitations will be improved in the future, as technology
> mature, but it will certainly take time.
>
> But even if CMP is perfect, why we need them?
>
> If the client does not talk with them, They only accessed internally to
> the server.
>
> Entity beans are heavy they required stub, skeleton, home, component side
> object the bean itself and more,
> I may be wrong here in the list of objects required but I think
> Entity Beans are still heavy compared to simple java classes.
>
> So:
>
> Does entity beans are useful (either now or in the future) for real world
> database application?
>
> Maybe what is required is a different standard that fit better to map Java
> objects (without the remote features) to databases
> something like TopLink, JavaBlend or Cocobase?
>
> Meanwhile is there some design patterns that can be used to design today
> persistence objects that can provide some acceptable performance with
> current technology and are easy to migrate once a better one come?
>
> Any other ideas how to implement domain logic as objects?
>
> Regards,
>
> Muly.
>
> ==========================================================================
> =
> 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".
