Richard,
Consider a situation in my application.
I have a BillingAccount object. BillingAccount has Customer, ContactDetails
etc.
Customer has an Address. ContactDetails also an Address.
Our design might be primitive. We have gone for fine-grained CMP
entitybeans viz BillingAccount, Customer, ContactDetails and Address.
Out database has corresponding tables viz BillingAccount, Customer,
ContactDetails and Address.
customerId and contactDetailsID are foreign keys in BillingAccount table.
addressId is a foreign key in both Customer and ContactDetail tables.
According to the (coarse-grain) pattern suggested in this thread, I should
be wrapping Address into Customer EJB and ContactDetails EJB ie I need not
have an Address EJB.
But how can I have a CMP Customer EJB which will manage persistence of two
tables - Customer and Address?
My understanding is that a CMP EJB can represent only one table (unless I
insert my own JDBC calls inside the CMP bean).
I am using WebLogic. It WebLogic Deployment Descriptor, I can point a CMP
EJB to only one database table.
Hope I have managed to make it clear.
Thanks
ashwath
----- Original Message -----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: Ashwath Narayan <[EMAIL PROTECTED]>
Sent: Wednesday, April 26, 2000 5:22 AM
Subject: Re: EJB Design: entity beans and domain objects
> Hi Aswath,
>
> This is a pretty broad question. Can you be more exact?
>
> Thanks,
>
> Richard
>
> Ashwath Narayan wrote:
>
> > May be this question too naive for the standard of discussion going on
in
> > this thread.
> >
> > How to design CMP entitybeans if I were to wrap many fine-grained
business
> > objects with a single entitybean?
> >
> > Thanks
> > ashwath
> >
> > ----- Original Message -----
> > From: Richard Monson-Haefel <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, March 16, 2000 11:53 PM
> > Subject: Re: EJB Design: entity beans and domain objects
> >
> > > 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
wit
> > h 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".
>
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition
> Published by O'Reilly & Associates
> http://www.EjbNow.com
>
===========================================================================
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".
