Dear All,
In our design team, we are in the middle of an 'idelogical' discussion regarding the
desired boundaries between entity and session beans in our product's
architecture.
According to one approach, entity beans should be simple, data-centric
objects with no interesting behavior - analogous to rows in a database
or C structs; all 'business logic' should reside in session beans.
This 'dumb-entity' approach has 3 rules:
(I) Entities have no behavior - all methods are accessors like get()
and set() .
(II) Entities are blind: they never use sessions or other entities.
(III) All client interface is through sessions (do direct access to
entities).
The alternative approach allows entity beans to have business logic,
and uses session beans for cross-entity operations or as an 'insulation
layer' between the client and the entity beans.
The dumb-entity approach has benefits and limitations:
Benefits:
=========
Stable persistence model: Changes in the business rules only affect
the session beans, so the persistence model remains unchanged. This
can be especially important if we use CMP.
Fewer design decisions: The boundaries between entity beans and session
beans are very clear: data goes into the entity beans, behavior into
the session beans.
Modularity: Since entities have no behavior they know nothing about
each other. A change in an entity will only affect the relevant
sessions ( and we usually only have a single session dealing with each
entity).
Context: If operations depend on client context information ( like client
preferences), that information can be naturally accessible in a session
bean.
If entity beans have context-dependent, 'smart' operations, the context has
to be passed to them via method arguments - which can be cumbersome.
Limitations:
============
Performance: Operations can require a long 'Ping-Pong' between a session bean
and the relevant entity bean(s). Since inter-bean communication is slower
than intra-bean communication, the performance is degraded. We are afraid that the
effect can be disastrous in the case of heavier operations on complex entities.
Awkward Programming: Being used to OO, moving behavior to the session
beans feels like going back to C. All behavior is expressed in terms
of functions and everything must be passed as an argument. It is
possible but difficult, and the resulting code can be hard to
understand. It can also be very annoying.
Conclusions:
============
My personal conclusion is that dumb-entities should be limited to cases where the
entities are small and simple.
In the case of complex, coarse-grained entities, the approach is
difficult to implement (no OO) and may lead to unacceptable performance.
In the simple cases, I am not sure whether the benefits outweigh the price.
I'd really like to receive your opinion.
Youval Bronicki
Sungard Business Integration
http://integration.sungard.com
---------------------------------------------------
Get free personalized email at http://www.iname.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".
