> The point here is that EJB is an implementation technology and has so
> many weird design quirks/flaws that its requirements should not make it
> into your domain model. Also, the common practice of somehow mystically
> grouping domain objects together under, say, an entity bean facade is
> not (a) easy or (b) practical in most cases (at least IMHO). So all I'm
> saying is: what if you did it the other way? What if you stick an
> entity bean under a regular java object "facade" (I use quotes because
> it's not really a true Facade in the Design Patterns sense)? And as
> long as you're doing that, why not shove session beans under regular
> java object facades as well?
The one issue I see is this: the advantage of a SessionBean Intf is that
I get one interface over what may be a slow socket - on the server side,
where connections are fast, I can leverage all of the EJB overhead, then
send the thin result back down the original slow connection.
With your approach, if I put in my client the domain objects that wrap
the EJB objects, then I have lots of EJB connections being made to the
server over that slow link to service each of the EBeans.
This is especially horrible if I have many objects involved in some
transaction whose result may only be a number.
As I see it, in that conext, you lose one of the primary advantages of
the session bean interface. Of course, there are many conexts in which
the difference will be small/negligible.
tim.
Tim Endres [EMAIL PROTECTED]
ICE Engineering, Inc. http://www.trustice.com/
"USENET - a slow moving self parody." - Peter Honeyman
===========================================================================
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".
