> The common counterexamples given to this point of view are OrderItem
> (which may be the only valid one I've seen) and Address. OrderItem is
> only not shared among orders in a simple, standalone purchase order
> case. You can easily conceive of other ordering systems that require
> both Order and OrderItem to be shared (we're working on a couple right
> now--they're common in digital marketplaces). And Address is shared the
> minute you start talking about common address books (as in customer
> relationship management applications). Products have product
> descriptions, but those are often shared, and so on and so on and so on.
>
Overall, I agree with your description of domain object <=> enterprise bean
mapping. My main observation is that the type of relationships that a domain
object participates in often dictate whether that object should be modeled
as its own entity bean, or as part of another.
Several object modeling approaches use the following classifications for
inter-object relationships:
Dynamic Association is the weakest form; Object A knows about
Object B at run-time (typically because a method of Object A
accepts a reference to B).
Static Association is a marginally stronger form; Object A maintains
internal state that refers to one or more instances of Object B.
Aggregation is a stronger form; Object A has a whole-part relationship
with one or more instances of Object B (Object C, D, etc.). Some
significant aspects of aggregation relationships are:
* The aggregating object usually exhibits one or more "emergent
properties" that don't occur with an arbitrary collection of
elements (i.e. an Order is more than a set of OrderItems, it
also has discounts, taxes, shipment and payment instructions).
* Aggregations must exhibit the property of transitive closure.
If object A aggregates B, then B must be a part of A. If B
aggregates C, then C must be a part of B and A.
* Often, the aggregating object will allow the identities of its
parts to be externally visible (allowing them to participate in
other associations, such as when OrderItems are associated
with ProductSalesHistory object).
Containment is a stronger form of relationship than Aggregation, where
that the part is tightly coupled with the whole. The containing object is
responsible for both the storage and lifecycle of the contained objects.
* Containments must exhibit the property of sole membership
(i.e. parts can only belong to one whole at a time).
* External objects must interact with the containing object to
delete any of the contained objects.
* When the containing object is deleted, the contained objects
are deleted with it.
Inheritance is the strongest form of relationship, enabling the derived
object to acquire properties and behaviors from another.
Domain objects that represent a part in a containment relationship should
not be modeled as Entity Beans.
Domain objects that represent a part in an aggregation relationship are a
little trickier. An important issue is whether:
a) the part has a lifecycle that is distinct from its whole,
b) whether that part participates in an association relationship
with other objects outside of its aggregation hierarchy, and
c) whether these external associations can outlive the aggregation
If all of these cases are true, then it's worth considering modeling the
domain object (that represents the aggregation part) be a distinct bean.
These shouldn't be the only criteria. Practical considerations, such as
performance and scalability play a role also.
On the surface, your example above of Order and OrderItem, seems like it
might represent a Containment relationship. However, the fact that OrderItems
have meaning apart from the Order (and even after the Order is deleted) makes
it more of an Aggregation relationship. Specifically, OrderItems are often
retained for sales history purposes (aggregate by product or by territory, etc.)
long after the detail of the Order has been deleted or archived.
Charlie Alfred
===========================================================================
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".
