> Another way to think of the whole domain-object-to-EJB problem is
> backwards. What if your domain objects wrap your entity beans where
> appropriate and do not where not appropriate?
>
> That is, the Party Line is to wrap your dependent objects behind an
> entity bean facade. What if instead you wrap your entity beans behind a
> regular java object facade? Then you can decide whether the
> "implementation" of a given domain object should delegate out to a
> backing entity bean or not.
Interesting thought, I assume you mean having the session bean calling a local
object wrapping the entity bean, with the session bean still acting as the remote
facade. As far as I can see the benefits of this would then be:
* Having a more abstract interface to your business logic. I like that. If you put
the whole thing behind a interface you will also be implementation independen. Hmm
... could be a good idea.
* Being independent of the current EJB spec and the app server implementation of
that. Good one too.
* Maybe one could solve the issue of relations between entity beans this way. That
would be great.
I guess it does not totally solve the issue of being totally OO with entity beans,
but it is a good start. Could it be that by doing this you will at least leverage
your business interfaces from EJB level? I'm going to let this one sink in a bit.
Regards,
/Marcus
Marcus Ahnve
Sun Java Center
Sweden
===========================================================================
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".
