Hi
After going through so much discussion there are a few things that lie
still unresolved
1."Entity beans should be ideally accessed through Session beans"- This is
what all the Ejb gurus say. If that is the case, why make entity beans
remote objects at all?. The answer that some app.servers might optimize
remote calls to local calls when the beans are co-located(i.e in the same
VM) is side-stepping this issue.
2. Since Entity beans are supposed to be accessed from a Session bean(The
"facade" pattern) why do we have separate transaction attributes for Entity
beans- these attributes could be controlled from the Session Bean itself.
3."Another function of Entity beans is persistence". The persistence
mechanism for Enitity beans in EJB1.1 was fairly crude. The EJB2.0
addresses some of these issues,but it is yet to be finalized. It might
bring forth other issues. See
http://www.onjava.com/pub/a/onjava/2001/02/28/ejb.html.
Regards
Anup
John Harby
<jmh_inc@HOTMAIL. To: [EMAIL PROTECTED]
COM> cc:
Sent by: A Subject: Re: Entity beans vs DAO(Data
Access
mailing list for Objects)
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
03/26/2001 11:47
AM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
I thought the relationship between JDO and EJB was not competitive but
cooperative. From the JDO .8 draft, sec. 1.1 -
"There are two major objectives of the JDO architecture: first, to enable
pluggable imple-mentations of data stores into application servers; and
second, to provide application programmers a Java-centric view of
persistent
information, including enterprise data and locally stored data."
>From: James Cook <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Entity beans vs DAO(Data Access Objects)
>Date: Mon, 26 Mar 2001 11:11:08 -0500
>
>----- Original Message -----
>From: "Geert Mergan" <[EMAIL PROTECTED]>
>
> > - can anyone give me one or more good reasons to go for entity beans?
>They
> > seem like a bad solution from everything I read so far in various
>resources
> > on the net..
>
>There seem to be many people on this mailing list that have problems with
>entity
>beans, but most often they don't seem to have any real evidence. It is
more
>like
>an urban myth. :)
>
>I think Entity beans are a good mechanism to represent a persistent
>business
>object. Many of the "problems" that developers have with entity beans
>center
>around things like concurrency control and the complexity of coding
>course-grained beans. Unless you are using an EJB 2.0 (maybe it won't be
>until
>3.0 until this is actually made easier) implementation or some
complicated
>framework (TopLink), this will always be a complicated task.
>
> > - If I understand well, Sun's JDO spec has not yet been implemented so
>while
> > waiting for such an implementation, do you think Castor's JDO is a good
> > alternative + why (not) , eg. does it follow part of the Sun JDO spec?
>
>Perhaps you have looked at JDO and can enlighten me. What will JDO get you
>that
>CMP doesn't already offer? I view JDO as a declarative persistence
>framework.
>The same challenges face the developer that uses JDO as the developer that
>uses
>Entity Beans. JDO seems like a good alternative for persisting objects
>*outside*
>of the EJB framework, but if you know you will be using EJBs, why bother?
>
>jim
>
>
===========================================================================
>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".
===========================================================================
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".
