Look everyone, a smart person posted!
Your goal is for Individual and Org to both extend Party, but you're
struggling with the spec not addressing entity beans extending entity
beans. What you're implying is that you want Party, the base class, to be
an entity bean. If that is in fact one of your requirements, then don't
read on.
Another consideration is to model Party as a plain class (a helper class),
and still extend it same as before by your entity bean classes. I'm almost
certain TOPLink could map such a construct, since it handles entities
extending entities. By using a helper class as the base class, you remain
100% within the spec.
One short-coming that would arise from my suggestion is if you have other
classes that you wish to return a PartyPK. If Party isn't an entity bean,
then no PK class will exist. That means those other classes would have to
return a Party helper class reference, which might not be the right thing
at all, and it also might be the area where the O/R mappers stumble.
David
Laird Nelson
<LNelson@CHANNELW To: [EMAIL PROTECTED]
AVE.COM> cc:
Sent by: A Subject: Mapping domain model to EJB
constructs
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@jav
a.sun.com>
12/30/99 08:37 AM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
OK, I've just spent (quite literally) three hours reading the archives
(searched for all messages containing "inherit*" in them, and read them
all!
{staggers out for coffee}) on the subject of inheritance (and the really
sad, sad, sad lack of it in the EJB 1.1 specification--what were they
*thinking*?), and now, hopefully better informed, I have a few questions.
I see from the archives that the only problems posed by an entity bean (E2)
inheriting from another entity bean (E1) are that an E1.findByPrimaryKey()
has no way of knowing (currently) if the reference returned is, in fact, a
reference to an E2 instance. I accept that there are hacks that one could
(quite easily! Why aren't they in the spec?!) use to get around this
problem--i.e. a discriminator column in each database table (
http://www.chimu.com/publications/objectRelational/
<http://www.chimu.com/publications/objectRelational/> ) coupled with
something like a getRemoteReferenceClass() method--but since they aren't
part of the specification (yet; they should be!), I don't want to use them.
OK, then. So I have this domain model, that actually doesn't use
inheritance *that* much, but does use it in a few of the standard and
extremely useful places. For example, I, probably like everyone else in
the
world, have a Party class (has a name, contact information, an address
book,
etc.) which is extended by an Individual class and an Organization class.
Parties can play Roles in Relationships, so, consquently, thanks to
inheritance, a NonProfitOrganization, for example, which extends
Organization and thereby Party, can play Roles as well.
Fine and good. Now I come to EJB, and I see that the specification does
not
support inheritance in any way. Rrr.
Assuming that entity beans are the beasts of choice for most of the
concepts
in my domain model (read the archives on that too; I recognize that not
every object in my domain model is by *default* a candidate for an entity
bean, but very few objects in my domain model are wholly contained by
others
or are stateless), how can I map my domain model onto EJB constructs?
(I remember reading an article in the archives that suggested something
rather vague about "overlaying" an EJB construct "on top of" my domain
model, whatever that means. I believe that article could be rephrased much
less cloudily :-) by saying something like, "Entity beans do not always map
one-to-one with domain objects. Frequently, they can encompass several
domain objects. Of course, you need to make sure that the domain objects
that a given entity bean encompasses have the same types of lifecycle
issues." So that's not the question I'm asking.)
If this is a FAQ or is otherwise annoying :-) I'm happy to take this up
with
someone via private email.
Cheers/Happy New Year to those to which it applies,
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".
===========================================================================
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".
