Anne,
>I like session bean wrappers because I really like the MVC pattern -- the
>client represents the view, the entity beans represent the model, and the
>session beans represent the controller.
We are also fond of the MVC pattern. Going through the various systems we
designed, I have to report that we use the pattern in all of them. However,
after the initial design phase, we always seem to conclude that the
controller should be broken up into two parts: one half private to the
creating client and the other half sharable among clients. To increase
performance and scalability of our architectures (through sharing and
caching server resident data) we use entity beans for this second half.
While on this subject, I also want to point out that we often use multi-tier
persistence. Our domain entities are always persisted "long-term". The
entities in the controller most often are persisted "short-term" (not
outlasting the server instance and local to the server) thus not affecting
the schema of the domain.
>In many applications the view uses multiple model instances. If the client
>works directly with the entity beans, then the client has to get a
reference
>for each entity bean instance. If you wrap the entities with a session
bean,
>then the client only needs one reference. The session bean manages all of
>the references to the entity instances. This approach definitely reduces
>resource requirements (one OUT reference versus many OUT references).
This sounds very nice on paper, however, in practice that one session bean
very fast becomes a monolith, you loose flexibility and, most importantly,
you are forced to ignore encapsulation (and all the other advances in OOP).
This is not to say that we don't use concentrators. In the systems we
architect, we use multiple concentrators, some of them implemented as
session beans while others as on-the-fly, sharable entities (e.g. our
EJBCollections used in querying entity domains).
>You could implement the controller function using an entity bean (using a
>session ID as the primary key). This approach has some significant
>advantages -- the session data could be persistent, so you could easily
>recover a lost session.
Of course, neither this nor any other of the above techniques for boosting
server resident data sharing/caching and improving scalability are feasible
if the platform does not allow releasing unreferenced entity objects.
Imre Kifor
Valto Systems
===========================================================================
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".
