All EJB patterns that I've seen so far say something similar, viz. that
if you have one class (say, an Order) that has a bunch of "dependent
objects" (the example always given is OrderItem) then in general the
first class (Order) should be modelled as an EntityBean and the other
class (OrderItem) should be modeled as a plain-Java serializable object.
It is of course important if you're going to apply this pattern to know
what is meant by a dependent object or class. Could someone who knows
such things expound on what is meant here, preferably one of the pattern
authors?
To spark the discussion, in the following sample code, assuming that any
OrgUnit instance cannot be shared between two Organizations, is OrgUnit
a dependent object or not?
Organization orgBean = (Organization)orgHome.findByXYZ(xyz);
OrgUnit orgUnit = orgBean.getOrgUnit("foobar");
orgUnit.doSomething();
My original take is that OrgUnit is indeed a dependent object, given
that it is owned by its parent Organization.
That is, originally I modelled OrgUnit as a serializable object, like
so:
public class OrgUnit implements Serializable {
private final Organization parent;
public OrgUnit(Organization parent) {
super();
this.parent = parent; // sets final var once and for all
}
}
Note that OrgUnit stores references to the *remote interface* of the
Organization entity bean. I was under the impression that this was OK,
and that, furthermore, it was still true, even with the implementation
above, to refer to OrgUnit as a dependent object; consequently storing a
reference to the remote interface of Organization was OK, and
implementing OrgUnit as a plain serializable object was OK.
But I then had it pointed out to me that if OrgUnit is really to be a
dependent object, it should look like this:
public class OrgUnit implements Serializable {
private final OrganizationBean parent;
public OrgUnit(OrganizationBean parent) {
super();
this.parent = parent; // sets final var once and for all
}
}
...that is, that if it was TRULY to be a dependent object, then it must
be activated and passivated with the bean class that is managing it.
Anything else--like storing the remote interface instead of the bean
class in the "parent" member variable--would render this class not
dependent, whatever that means.
Among other implications, this would mean that the client could never
create an OrgUnit and assign it, once and for all, to an Organization.
Only an OrganizationBean could create an OrgUnit. Why? Because
OrganizationBean--the bean class--is available only on the server, and
is never exposed to the client. I was told that this was a necessary
condition of something's being a dependent object in an EJB
environment. That sounds wrong to me. What if I want to support
something like this:
// client side
Organization o = // get it from somewhere....
OrgUnit purchasing = new OrgUnit(o);
...?
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".
