This is a great discussion.
I for one have been uncomfortable with the assumption of 1-row = 1
entity bean.
This idea seems to be driven by implementation details - perhaps that of
CMP though I
don't know if that is true.
I do believe that entity beans are objects... but that not all objects
are entity beans.
The reason that we have problems with beans being objects is because
they are
already partially designed - and sometimes the design constraints put
on them
get in the way of other things we would like to do. For example, entity
beans are
designed to be distributed: great, but distribution entails rmi, entails
overheads. I don't
think that is what we want from all our objects but that doesn't
distract from the beauty of
EJB either.
Ian's thoughts on developing the object model then partitioning that
into beans are
well received in this regard. Aggregation level is dependant on
required interaction with other beans.
Thus my bean might be composed of several interacting classes but which
for the purposes
of my application can export one combined interface. I drive a car but
don't really need to know how the
transmission talks to the engine (well almost!). However, if I repair
cars, then I do. The beans might
look different for these separate applications but they still could be
composed from the same library of objects.
What is more, if I build persistence into the classes then if I use bean
managed persistence I can ask the components
to store themselves.. but this is another issue.
One more implication of this design.. If I were to naively translate
each class into a bean, then I would have
a 'Distributed Car'! Something most of us would rather not have and in
any case its performance would not
impress!
Jon
===========================================================================
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".
