Though I agree entity beans are not of much help, I find entity beans useful
in some situations like:
- A table with limited records and requiring updation creation of records.
This can be done by a CMP in zero coding time.
-----Original Message-----
From: Simon Blake [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 26, 2001 11:42 AM
To: [EMAIL PROTECTED]
Subject: Re: Why use entity beans? (No good reason!)
Sachin,
Given that I feel so strongly about Entity Beans being a colossal waste of
time,
I can't go away with a clear conscience without responding to your message.
Entity Beans have shocked me into disbelief - I cannot believe that anyone
thought they were a good idea -
at any stage. I read through the EJB 2.0 specification with a sinking
stomach - could anything really _be_ this bad I asked myself?
I think that many vendors out there will be looking at the spec and
thinking, "Can we convince Sun to make this optional? Cause
it is the worst waste of time, the most embarassing specification in the
history of specifications!" I mean, if Microsoft made
specs then you would have something to compare it against, but it is pretty
much on the cusp!
That said (IMHO of course), your points.
----- Original Message -----
From: "Sachin Aggarwal" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2001 9:39 AM
Subject: Re: [EJB-INT] Why use entity beans?
> I agree that people tend to use entity beans when they want to use one of
> the following features provided by entity beans.
>
> 1. CMP - apps where OR mapping is pretty simple
Various tools, such as cocobase or toplink make this more viable, but it
doesn't get around to the fact that Entity Beans
exist to provide an independantly scalable data logic layer. And unless you
have an extremely speedy layer between your
session beans and entity beans, this is utterly, utterly pointless. All
Entity Beans do is get in the way of making EJB applications
easy to develop.
> 2. Locking model -
> a. pessimistic
A generally looney idea IMHO - applications do not scale with pessimistic
locking, we know this from basic Client/Server principles. But
if people want to do this, there is no reason that a data layer can't do
this as or more effectively that an intrusive Entity Bean layer.
> b. optimistic - involves creating copies and synchronizing
> with server cache.
> - this is a powerful feature for several apps which most ejb containers
will
> give you.
But a straight data layer like JDO might give you is much, much better at
this than Entity Beans IMHO. Many O/R mapping
tools go out of their way to provide you with options for making this a very
sensible option.
> 3. Server caching
Again, a good O/R mapping layer does this better without interfering in the
mechanism and making database work painful like
Entity Beans do.
> 4.Declarative transactions- some entity objects require seperate
transaction
> semantics - other than those passed in by session beans.
But you will use Session Beans over Entity - so your Entity Beans are always
MANDATORY or REQUIRED (or maybe REQUIRES_NEW,
but I can't see why) which means their transaction status is irrelevant. The
Session Bean will always ensure a transaction has been started and thus, the
data
layer will data declarative transactions anyway. .
> I feel that for some projects , this is a lot of work to do in-house so we
> shouldn't just give up on entity beans.
It isn't any work at all - just use a JDO like product - or some other
mechanism,
there are lots around and they do the job rather well!
> Also, as far as passing the entity java objects to the client is concerned
I
> wanted to point out that it might be better to use copy objects instead of
> serializing the java entity objects residing on the server.
Anyone who does is in the risk of doing something quite silly, first it is
against the
spec (from memory) and second you can get weird things occuring on the
client when
the objects try and finalise when they aren't referenced anymore. There are
all sorts
of different workarounds for trying to get Entity Beans to work but I
believe (and have seen
with my own two eyes) that the time wasted in implementing those workarounds
could be
much better spent investing in some decent O/R technology.
Really.
Simon.
===========================================================================
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".
