Brian N. Miller wrote:
> Chris wrote:
> >
> >On partitioning the graph, it may depend on the underlying technology.
>
> My point exactly. I seek entity design heuristics which minimize the
> human intervention required to map into persistence, REGARDLESS OF THE
> UNDERLYING TECHNOLOGY. That is, I'm looking for entity persistence
> *portability* guidelines, so that I don't have to master designing for
> alternate persistence mechanisms. Small, disjoint entities seem the
> best *general* pattern for easing persistence mapping.
>
This is an admirable objective. Unfortunately, the objective may not be
practical because components are not objects and do not enjoy the advantage of
operating in the same address space. I think its possible to compromise by
making entity beans CMP and independent of the implementation (EJB server and
type of database) while session beans should be created to leverage the
deployment platform. Session beans manage the interactions of other entity
beans but they also perform other services like listing. Listing is an
especially good example of this compromise as demonstrated below.
OLTP Business systems (what most of us build) use a great deal of listing
behavior in the UI. To get, for example, a list of all customers for a
specific sales person for 1998, a query must be run. If your system is composed
of only persistent independent entities (CMP) then you must transverse the
component graph or build find methods for all anticipated listing needs. The
first option, transferring the component graph, can have real performance
implication since each association must be resolved as a remote reference(s)
and transversed. The later, finds for every listing behavior, is simply not
practical since the types of list needed change as the UI changes; you would
end up with many, possibly hundreds, of find methods on each entity type.
An alternative solution, one I believe is the most practical, is to place
listing behavior in both entities and session beans. Listing behavior that is
specific to the entity type is manifested in find methods and driven by
attribute value. As an example, you can give the customer bean a find method
that returns all the customers that are located in a certain area. Find
methods should be limited to queries specific to only that entity. Listing
behavior that spans entities, like the customers for a sales persons, would be
included in session beans, not entity beans. Session beans that define a
screen or use case (depending your approach) usually use listing behavior that
is not reused in other scenarios. Since these listing behaviors are specific
to one scenario, the session bean that models that scenario should implement
the listing behavior directly.
Find methods can be implemented by the container (CMP) and are not specified in
the bean itself. This guarantees that the entities are platform independent.
Listing behavior that is manifested in session beans (lists that span entity
types) should not transverse the component graphs to create the list. Instead
these listing behaviors should leverage the query capabilities of the
underlying persistence store directly. If you use a relational database then
dip into it using JDBC and SQL and create the list. Return the list as some
kind of table (multidimensional arrays, ResultSet, an array of row objects,
etc.) This makes the session beans dependent on your persistence layer, but
it also ensures that your system is performant. When you change persistence
layers you will need to rewrite theses queries but that is hidden from the
client by the facade of the session bean.
Entity beans can be implementation independent (CMP) but this is not always the
case with session beans. In addition managing workflow and providing
non-entity services (e-mail, stock ticker, etc.) session beans should be
leveraged in operations that would be to clumsy to implement with entity
beans. Listing behavior that crosses entity concepts is a good example.
Another related behavior is reporting. I would advise you never to implement
reporting using entity beans -- its a real bad idea.
You can also introduce non-ejb mechanisms to create implementation independent
behaviors; JNDI for singleton behavior, JMS for messaging, or custom constructs
like IT Ship's UUID generator for auto generating unique Entity primary keys
are examples.
--
Richard Monson-Haefel
Senior Consultant
BORN Information Services
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
(Available June 1999)
===========================================================================
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".
