> Hmm. Actually, when I wrote the message I meant something even more
> decoupled than this.
*snip*
> 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.
IMHO it is a <overused term> component model </overused term> doing a
lot of stuff that you can write yourself, but it is so nice to have that
done by somebody else. However, if there is a new shiny component model
doing things twice as fast at half the price next year I for one is not
too keen on rewriting the whole thing. Therefor I like the idea of
keeping the business model separated from the component 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)?
Adapter maybe? But if they would not only change the interface, they
would also have a bit of implementation maybe steering calls to
different beans.
> And as
> long as you're doing that, why not shove session beans under regular
> java object facades as well?
Sure, as far as I see that means adding an adapter at all client levels
- but that is just like most people do for isolating the database for
example.
> Hope this clarifies my (tentative!) thinking a bit.
Yep, I think I like it.
/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".
