Assaf Arkin wrote:
> I was actually referring to (spec not in front of me right now) to where
> it states that entity beans should be used for coarse grained objects,
> not for fine grained objects. If your database consists of many fine
> grained objects, you are advised to use entity beans only for the large
> blocks.
>
> This advise takes into account the performance hit of EJB, and the fact
> that the EJB model is best for handling the business data + process, not
> just the plain data.
I agree. As the EJB spec currently stands, entity beans seem more
suitable as a distributed component, not as a distributed object.
By this I mean that it's more of a deployment and packaging platform.
(Clemens Syperski's "Component Software" book has an excellent
discussion of the differences between components and objects.)
To use entity beans well, it seems (to my understanding anyway) that
I would design the persistent object structure, and then pick the
points at which I want to provide a distributed interface, with the
associated transaction, synchronization, security, and life cycle
support. I make those object interfaces entity beans.
As you point out, sometimes these interface points are at the head
of either a collection or graph of associated objects, and won't
necessarily map one-to-one to a business object.
As you mentioned in another message, entity beans will certainly
benefit when there are more standard mechanisms for handling these
associated objects, like JDO, and good persistence mechanisms that
can do things like lazy instantiation. There's some good stuff out
there now, for example (in no particular order) Gemstone, TOPLink,
PowerTier, and Javlin, but using them means committing to a
proprietary technology (yeah I know that they all support standard
entity beans, but by the time I develop for the product, install it,
deploy it, etc., I've made a pretty big investment in it and I don't
think I can switch between them very easily - the vendors are
welcome to correct me here ;-).
> Anyway, with all these discussions I've considered writing something to
> explain the technical issues behind entity beans. There's nothing like
> writing an implementation to understand what it does best and what it
> does only partially good.
Go for it! I'd certainly look forward to it.
-Paul Hodgetts
===========================================================================
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".
