> -----Original Message-----
> From: Hansen, Richard
> However, if your entity beans
> have business logic, can you get that with JDO?
I hope that JDO standardizes O/R mapping tools like
Castor, Cocobase, Toplink and the alikes.
I don't know exactly how JDO works but I hope it will
working according to the principle of Castor and toplink:
a configuration file contains the O/R mapping and the
business objects don't know of the persistence layer's
existence. Can someone confirm that this is how JDO works?
> Even
> accessing all entity
> beans through session bean facades does not mean that the entity beans
> will/should have no logic of their own.
Agreed. Entity beans can contain business logic, but I'm not sure
whether that's a good idea. I know of two companies where they use Weblogic:
1) Session beans as a facade to java classes made persistent with an OO
database.
2) Session beans and entity beans
The guys at (1) are very happy with EJB.
The guys at (2) are not too happy with entity beans and would
like to remove the entity beans but because their entity beans contain
business logic they just don't (the costs are too high) and they keep being
stuck with entity beans.
> Componentization and reuse would be another reason to use
> entity beans. If
> you persist objects without out using entity beans, I expect
> that every
> developer is more likely to recode the object persistence as
> needed. Without
> entity beans you are relying on code reuse, not component
> reuse. It seems to
> me that entity beans represent a better encapsulation and
> location mechanism
> that just relying on class files.
If you talk about reuse in the third-party sense then I agree. It's
possible to sell entity beans to third parties. This is not
possible with persistent java classes.
If you talk about inter-project reuse within a company then I disgree.
If every project accesses the business model via session beans
reuse will work fine. Even the location mechanism will work (I suppose
you talk about JDNI location of home interface). I recall company (1)
mentioned above. They are OO purists in the sense that they have a
framework (in the true OO sense) that is being customized for several
clients. Reuse works for them.
> Some of the same entity bean performance issues can be rasied
> about session
> beans. Obviously you don't have the performance issues
> related to database
> synchronization. But you still have network communication,
> object lookup,
> and container performance overhead. If you were to make your
> session bean
> functionality too fine grained performance would suffer.
I disagree. Sure, to execute a business scenario (in the UML sense)
you need to do one session bean call. But after that, all your calls
remain within the same VM and you don't suffer from
entity bean lookup and entity bean relationships.
geert
===========================================================================
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".
