Ian,
How about an example of your approach? I�ve heard a few people talk about
coarse-grained entities that encapsulate business object graphs, but I don't
have a clear idea of how this would work. I tend to believe that this would
lead to an inflexible manifestation of the business model. Of course
fine-grained objects like Address should not be entities -- even the
specification states that (dahh!), but your approach advocates encapsulate
coarser grained business objects within an entity bean? What Java classes
(objects), for example, would a Customer bean encapsulate? Pick a customer
from any domain.
Thanks,
Richard
-----Original Message-----
From: Ian McCallion
To: [EMAIL PROTECTED]
Sent: 5/20/99 7:31 AM
Subject: Re: sessions wrapping entities
Agree with all you say, except use of a session bean to wrap a
collection
of entities. Why not push the wrapping further back and use an entity
bean
to wrap a collection of java classes? Performance will go way up
(EJB->EJB
calls are expensive), and there will be no possibility for accessing any
interfaces other than the "dumbed-down" ones.
===========================================================================
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".
