----- Original Message -----
From: "Geert Mergan" <[EMAIL PROTECTED]>
> Ha, finally, the opportunity to give my anti entity beans speach :)
Likewise, I enjoy this as well! :)
> - JDO offers a much better performance (this is not based on speculations
> but on experiences. I don't have experience with JDO I must admit, but I do
> have experience with entity beans) because entity beans are distributed. Why
> would you want entity beans to be distributed if they are wrapped by session
> beans?
You are stating that entity beans don't perform well, and that it has something
to do with a distributed environment. We all know that remote calls are
expensive. One of the core reasons for the session bean facade pattern is to
prevent a client making remote calls directly to an entity bean. Much the same
way you would not want your clients talking directly to JDO objects. The session
bean is deployed *together* with the entity beans. There are no remote calls
involved except for the original client request. It does not suffer any more
performance overhead than any other persistence implementation, including JDO.
> - It also allows to design your business logic as a true OO system. I think
> EJB 1.1 is much closer to the relational model than to the OO model. And if
> you look at how the EJB 2.0 doesn't get finalized as they try to move closer
> to being an OO model.
Finally, a valid reason against Entity Beans! ;-) Entity Beans do not relate
well to a finely grained OO model. After you have used JDO for some time, I
wonder what your take will be. Typically, fine grained objects in a persistence
system are very complicated and a performance drain.
> Okay, that's true. But given the two disadvantages of entity beans, I still
> don't consider this as a reason to use entity beans.
>
> I only need EJB for distribution, transaction management, authentication and
> autorization, but that's something of which session beans take care. So my
> question remains: why would I want to use entity beans?
I will only concede that entity beans do not support implementation inheritance
and therefore do not map well to some OO constructs. I always try to develop
using Value Objects, and it is these that support the OO design of my
applications.
If we are discussing JDO vs. Entity Beans with the EJB framework, I would say
its a no-brainer. Entity Beans have a well managed lifecycle supported by the
container. Why would you introduce another framework into the mix (add
complexity, maintenance issues, portability?, etc.) if you don't have to.
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".
