Laird raises an interesting design questions about the legitimacy of dependent
objects. I have some simple rules for determining if a business object is a
dependent object.
Dependent objects are defined as those business objects that are fine-grained
and dependent on the context of their aggregator to define their existence. In
other words, if the aggregator (the business object that owns or contains the
dependent object) is destroyed, then the dependent objects are destroyed. A
dependent objects is a somewhat complex object referenced by a persistent field
of the entity bean.
An geographical address (street, city, state, country, zip) is often used as an
example of a dependent object. A Person business object has a home address.
The address is a complex property of the Person business object and is
manifested as a dependent object in the person entity bean. It can be argued
that destroying the Person (removing the person's data from the system)
effectively destroys the address, just as it destroys other persistent fields
like the person's name, age, etc. This seems logical and right. At the same
time it can be argued that Address objects are shared by many persons. If, for
example, an insurance system maintains Person business objects for every member
of a family, its natural to assume that their address information is shared. Why
duplicate it?
Taken to an extreme we can define a model where every piece of data is
effectively shared. The name "Smith" for example is common to everyone with that
last name, so instead of duplicating that piece of data you could simply store
it once and have everyone with the last name of "Smith" share an entity bean
that represents that name. Obviously this is overkill but it illustrates a key
qustion: When is sharing effective and when is it simply possible? Deciding
what business objects can be shared and what are duplicated is a skill and some
would say an art, and for some its just arbitrary. In my case I apply a set of
simple rules for deciding if a business object should be a dependent object or a
shared entity bean.
The decision to make a business object a dependent object depends on the value
obtained when applying the rules -- a somewhat subjective test.
1. What is the scope and granularly of the business object.
This is usually a quick indicator that a business object qualifies as a
dependent object or an entity. Generally, very fine grained business objects
with a small amount of data and/or behavior can be considered very fine
grained. Address is a good example. It has perhaps 4 or 5 fields, some
validation rules, and that's about it. Address doesn't' require complex
business behavior.
2. Does the business object have meaning by itself.
If the business object has meaning independent of any other business object then
it an entity bean. If it doesn't have meaning outside other business objects it
should be a dependent object. An address, for example, only has meaning when
associated with some kind of entity. A person, place or thing. It makes sense
to lookup the address of an organization or person, but under what circumstances
would you look up an address for its own sake? Generally you wouldn't.
3. What is the cost of making a business object a bean.
In many cases we can leave performance as a responsibility of the vendor. This
is after their domain. It has even be suggested on this list that the
application developer should completely ignore performance when developing their
EJB systems and leave it entirely to the app server. Do what ever you like and
the app server will compensate for poor design. Obviously, I don't agree with
this. While EJB brings transactional processing to the masses it doesn't excuse
us from making intelligent design decisions to improve performance. Its obvious
to most people that creating a component graph where one entity references
another is costly. It costs resources and cycles to locate, obtain, and
maintain a reference to another bean. Obviously being able to reference other
entity beans from another bean is necessary, even critical to modeling the
business, but care must be taken when doing so. An address would, IMO, be a
poor example of an entity bean even if the data it represents could be shared.
In addition, there are transaction deadlocks to consider. Shared data means
isolated data under certain circumstances. The more shared data you have the
more instances of deadlocks you will encounter. Its a simple but possibly
explosive problem.
-- Richard
--
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
http://www.EjbNow.com
EJB FAQ
http://www.jguru.com/faq/EJB
===========================================================================
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".
