I'm not sure why everyone is under the impression that anything in a
database needs to be an entity bean. I never felt this, nor got this from
the Java community. I would recommend reading the SUN java Blueprints
document. They barely use entity beans at all. It is very well thought out
and has excellent recommendations on when to use, and when not to use entity
beans.
There is really only one time you would use an entity bean, when you have a
single row entity that needs to be modified, such as a user account. If you
are returning more that one row you are much better off with a session bean
that performs JDBC calls to the database.
Even when you instantiate an entity bean you don't always need to access it
on the client side. You can encapsulate the entity fields into a read only
serializable copy. This object can be passed by value to the client. This
means that the model object actually lives on the client, only one RMI call
to get the object in the first place. Note that in contrast entity beans are
passed by reference so that every call to access the fields of the EJB
require an RMI call.
That is enough of my 2 cents. I really got all this information from the
J2EE blueprints from SUN. I cannot recommend this online book enough!!
-Steve Rock
-----Original Message-----
From: Al Fogleson [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 26, 2000 6:21 PM
To: Orion-Interest
Subject: Re: How are database JOINS achieved with EJBs?
----- Original Message -----
> Al:
>
> YES. I'm starting off with the hypothesis that all database tables
> should map to EJBs, because that is what all the hype is about.
>
> Now, for real world, does it work well?
Yes and no. There is a terribly large amount of overhead involved in EJB to
begin with, then you start adding all the RMI calls over the network and
that adds some load too. In general we try to model our EJB such that we
minimize the Entity beans. Certainly they are handy, but let us take a
classic example of a person bean. A person also has an address, now
addresses dont change much so I really dont see a lot of sense in deploying
an address bean that will sit for most of the time in the pool and not be
instantiated. So I would just use a regular class (which may get a
datasource from the JNDI services) and do this address class using regular
JDBC. So yes entity beans work well, but we as a java community have
"fooled" ourselves into thinking that if it is a table in a database it
should be an entity bean.
>
> Is you answer that one should make create an EJB that
> is not CMP, but rather one supplies a hand crafter SQL
> command somewhere in its member functions?
>
Yes, you can use bean managed persistence to handle this. In your case it
should be rather simple since you seem to have a built in primary key (D)
so it would work easy. There are some situations, especially when doing the
kinds of things you are talking about where BMP is the only way to go.
Because of complex joins or the need for a complex primary key. it does put
more work on the bean developer but in some cases it may be the only way to
go.
Al
- att1.htm
