I use a somewhat similar design when I do this. But
the java-objects go above session-beans.
Actually it's just the "Standard Architecture of J2EE"
as defined by Gemstones Advanced Architecture Team (or
whatever they were called).
The main (architectual) pattern is that of the
ServiceArchitecture (I think this should go into the
WikiWikiWeb's component-pattern-language project...).
The key issue is to encapsulate the entire
business-logic into services-based facades (mainly
functional, but operating on "oo"-arguments). The
implementation may or may not use entity-beans for
domain, but when they are used they are primarily used
for persistence. The applications built above the the
services-platform are strictly oo and implements an
application-specific domain-model.
There are some issues regarding this. It does not
scale easily down to more simple systems. There are
some reusability issues regarding the
business-specific domain-model (the ones the services
uses to implement their behaviour) and the
application-specific domain-model.
For larger applications although one gets a
satisfactory reuse of business-logic (in the form of
services), and that's actually the main reuse-issue
doing a larger business-oriented system.
Also, one simply have to give up the idea of the
"perfectly" object-oriented business-system. But when
one gets used to the idea of a services-oriented
business, it's actually not that bad.
--- Laird Nelson <[EMAIL PROTECTED]> skrev:
> Marcus Ahnve wrote:
> > 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.
>
> Hmm. Actually, when I wrote the message I meant
> something even more
> decoupled than this. Using a bastardized version of
> Richard's book
> examples, TravelAgent would simply be a java object,
> and would
> correspond one-for-one with your first crack at a
> domain model in UML.
> The decision would come later whether or not you
> wanted to implement its
> work via a session bean "under the covers".
>
> So you'd have code like this:
>
> public class TravelAgent extends
> NothingInParticular {
> public void bookPassageOrWhatever(int someParam,
> Person person) {
> // want to implement this using EJB? Then do
> this:
> TravelAgentRI ta = // go do that JNDI
> voodoo...
> ta.bookPassageOrWhatever(someParam, person);
> }
> }
>
> public class Person extends YourMother {
> // care to implement this with an entity bean?
> Fine:
> PersonRI impl = // JNDI stuff
> public Person(String name) {
> // create impl if not created
> impl.setName(impl);
> }
> }
>
> 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?
>
> I'm sure there are flaws I haven't thought of. This
> is the product of
> only a couple days of thought.
>
> Hope this clarifies my (tentative!) thinking a bit.
>
> Cheers,
> Laird
>
>
===========================================================================
> 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".
>
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
===========================================================================
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".
