> >
> [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?
>
I didn't mean to preclude the second alternative (i.e. using an entity bean
to wrap a non-entity bean implementation of an identical abstraction).
>From a purely practical point of view, the non-EJB model may exist prior
to the EJB model (as your example below points out).
> 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?
>
I'm not completely sure I understand what you mean by "homogenous
containment hierarchy", but I'll make an educated guess. It sounds like
you are talking about something resembling the Composite Pattern. For
example, a Directory is a composite FileSystemEntry that holds other
FileSystemEntries (including other Directories). If you meant something
else, then ignore the next two paragraphs.
I think that a common approach is to designate a specific class (that does
not inherit from the homogeneous class) to serve as the top-level container
(FileSystemRoot in the above example).
The lingering question is how to model the "directory-like" properties of a
file system. One way is to have a FileSystemRoot hold a single Directory
(the root directory), or to use an interface called DirectoryAPI that is
implemented by both Directory and FileSystemRoot,
> 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)?
>
In spite of their considerable run-time overhead, entity beans do enforce
two useful disciplines because of their heritage:
1. They encourage the use of Java interfaces to represent the public
API for a component. This is especially helpful in those cases where
the implementation is subject to more volatility than the interface
(i.e. objects that encapsulates business policy logic, such as an object
to prioritize passengers on an airplane for rebooking). Clearly,
developers can opt for widespread use of interfaces to reduce the
coupling between classes, but it's been my observation that they don't.
2. They encourage support for location transparency. Yes, choosing to
extend java.rmi.Remote does this, also. But it's also been my experience
that lots of designs (including my own) make subtle assumptions about
dependent objects residing in the same address space. This should be
a conscious decision that balances configurability and scalability with
the additional overhead associated with remote vs. local calls.
Regards,
Charlie
> 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".
