Maybe we are actually talking about two kinds of inheritance here,
that we shouldn't confuse. First, there is behavioral inheritance.
You want to be able to call a Party function on both Individual and
Org. This is easily done within the current spec, using java
interfaces. You could write something like:
public interface Org extends EJBObject, Party
The second kind of inheritance is in the persistence mechanism.
You want characteristics of Party stored in a base table common
to both Individual and Org. This is easily accomplished using bean
managed persistence, and may or may not be easily accomplished
using container managed persistence or object relational mapping
tools, depending on the implementation. It doesn't require that a
bean use inheritance.
So "base classes" don't become ejbs; only leaf classes do. You
can even use common code--just put it in an ordinary java class
that multiple beans use. This is covered (briefly) in B.2 of the spec
(inheritance).
The one outstanding issue would be relationships between beans.
You would need to use a discriminator, as you said, and some sort
of factory to instantiate the correct ejbs. Here again, you don't
need inheritance of ejbs. Relationships aren't covered very well by
the spec, and weren't listed in Appendix A (features deferred to
future releases) so you shouldn't be reluctant to use the factory
approach when instantiating beans as you follow relationship
references.
Just my opinion.
On 30 Dec 99, at 11:35, Laird Nelson wrote:
> > 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.
>
> OK, let me ask this question. I was under the impression that it *would* be a
>requirement for Party to be an entity bean solely because I might have functions that
>should work on a Party, in much the same ways that they might be asked to work on an
>Employee, or a Company (both of which
definitely should be entity beans, if I read correctly). Is there a litmus test, or
something even approaching a litmus test, I can use here?
>
> > 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.
>
> Fine; what about the case where VendorCompany logically extends Company logically
>extends Organization logically extends Party? Which of these classes should be
>entity beans and which shouldn't?
>
> 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".
>
===========================================================================
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".
