Charlie Alfred wrote:
> 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.
>
[Randy Stafford] I like these heuristics, Charlie. I used some of
them in FoodSmart without knowing it at the time.
It seems you're using "domain object" to mean an abstraction in the
conceptual domain model, which might be implemented, according to the
heuristics, as either an entity bean or a "dependent object". Some
subscribers interpret "domain object" to mean an alternative (non- entity
bean) implementaton of the conceptual abstraction. Given this distinction,
it also seems that the application of your heuristics will result in
mutually exclusive sets of entity bean and non- entity bean implementations
of conceptual domain abstractions - in other words, there will be no
wrapping of (implementation) domain objects with entity beans. Is that
accurate?
In FoodSmart we started with a complete non- entity bean
implementation of the conceptual domain model (because of our backgrounds
:-) and later added wrapping entity beans for some of the domain object
classes. We have one interesting case not covered by the heuristics: a
homogenous containment hierarchy. Since it is homogenous, how to decide
whether to model the parts with entity beans?
Also, for projects that start with a complete non- entity bean
implementation of the conceptual domain model (either because they already
have one pre-dating EJB, or because they're not sure just what to do with
entity beans), do you see any other redeeming value in entity beans besides
the persistence hooks (which may be of dubious value in the presence of
other persistence mechanisms, especially considering the development and
runtime cost of using entity beans)?
Best Regards,
Randy Stafford
Senior Architect
GemStone Professional Services
===========================================================================
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".
