>
> A) Allowed and appropriate under the existing J2EE standards and
Yes.
> B) A good idea
Not under what you have in mind. Inheritance is source code reuse unless
you code(and maintain) very carefully, possibly using abstract methods.
You're stretching the concept somewhat in your example. A class
implementing EntityBean isn't an EJB. The XML descriptor(s) is also part
of the EJB and they don't offer the equivalent of inheritance. EQL
statements would complicate and resource management hints would be
erroneous.
>
>
> Suppose I have an entity bean called User.
> It has the following fields:
>
> Integer id;
> String username;
> String password;
> String type;
>
> and is mapped to a table called Users.
>
> I want to create a subclass of User called Researcher. I want
> the entity bean to have the following fields:
>
> Integer id;
> String username;
> String password;
> String type;
> String firstName;
> String lastName;
> String affiliation;
>
> I want to map the first four fields to the Users table and
> the last three fields to a Researchers table which would also
> have an id field for the purpose of joining the two together.
Uh... You could achieve this with just the Researcher bean and 2
"logical" EJBs by having 2 <entity /> entries in the XML, pointing them
to the same classes/interfaces. Bear in mind that some app servers won't
allow fields to be in different tables.
You can also inherit and/or reuse Interfaces this way:
class ResearcherBean {
void doAdminStuff() {
//code
}
}
interface AdminResearcher extends Researcher {
void doAdminStuff();
}
>
> Now I have two beans, one of which is logically a subclass of
> the other but which have no formal relationship as far as the
> EJB container goes, sharing the same database columns. When I
> want to manipulate all users I can use the User bean. When I
> want to deal with just Researchers, I can use the Researcher
> Bean. I can use the type field to inform me which users are
> also researchers if I ever need to know this.
You'll probably need to(know which ones are Researchers) since it's
likely you'll end up with just the Researcher table to hold data for
both Researcher and User EJBs.
>
> Is this legal and/or appropriate as far as the specs are
> concerned?
Yes, but your idea would work provided that storing fields in different
tables is possible. I know for sure Orion doesn't let you do it.
> Is it a good idea?
Definetly not because:
A) An EJB is the EJB class + interfaces + descriptors. Inheritance won't
deal with descriptors(both server independent and server dependent)
which will yield an elegant implementation but a descriptor hell (in
terms of maintenance).
B) It'll be a huge performance hog. Most caching and or commit options
would have to be disabled in order to maintain ACID properties, and
isolation and heuristic deadlock detection wouldn't be enforced properly
for these beans.
> If not, what other techniques
> are people using?
If I were you I'd use containment/composition instead. Simply have a
Researcher bean that either has a 1-1 relationship with user, or store
the matching user PK/Handle to find the associated User.
My 2c,
JP
===========================================================================
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".
