Hi,
I am jumping in quite late in this thread so apologies if I repeat something
already said. The one concept that always seems to go amiss in this thread
which appears again and again is that the concept of Entity Beans allow the
the swapping in and out of different bean implementations why still
supporting the interface contract. It is quite common in banking systems to
have the same interface lets say, Branch, deployed multiples times in the
jndi but which has a different bean implementation.
The implementation difference might be just at the deployment level in the
case of the persistence mapping (different datasource, different database
schema) or at the business logic level where some extra rules are applied.
By hiding this behind a remote it is possible to still have resuse at the
session bean level. We can have multiple packaging of the same session bean
code but different entity bean implementation. Typically clients will be
configured to bind into different naming services or lookup different names
in a service.
William Louth
www.borland.com/appserver
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Christian Riege
Sent: Thursday, March 29, 2001 11:39 AM
To: [EMAIL PROTECTED]
Subject: Re: Entity beans vs DAO(Data Access Objects)
hi,
> Yeah, entity beans with weblogic 4.51 perform really bad (BEA doen't
> deny, they say you should use tools like toplink for WL)
>
> Our architecture had a workaround to use a session bean and plain
> sql when a lot of "rows" needed to be loaded from the database. The
> workaround outperformed the entity beans by a considerable factor.
uh but that is a common pattern i would think. loading n rows from the
db via ejbFindByXXX results in at least n+1 queries to the DB (1 to
find the primary keys, n to instantiate the beans). this is clearly
inferior to using a single query and putting the resultset into DAO's
or whatever you might call them.
best regards,
christian
===========================================================================
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".
