Assaf Arkin wrote:
> Seesion beans are modeled after your business process, while entity
> beans are modeled after your business data. And so both will include
> business logic in their method calls.
I think I agree with this in theory, but it depends what you mean
by "business logic."
Business objects (or data) as represented by entity beans, are
usually used across multiple applications, at least if we want
some level of reuse in an enterprise architecture.
For a given application, we would usually represent its required
functionality as a set of use cases for the application. These
use cases will define the business logic required to support that
application. If we're creating an enterprise architecture to
support a suite of applications, we'll have a set of use cases for
each application.
I would caution against migrating use case business logic into an
entity bean, unless that business logic is intrinsic to the entity
and common to *all* applications. This type of common business
logic would be logic that is *only* related to the maintenance and
access of the entity data apart from the entity's use in any use
case. Examples would include the usual update/retrieve logic and
data validation logic.
If we migrate use case specific business logic into entity beans,
we end up with cohesion problems. As an example, we create
application #1, and entity A ends up with a few use case specific
business methods. Now we create application #2, and entity A gains
a few more. Application #3 adds a few more. Now entity A has
some methods that are only used by application #1, but not for
application #3, etc.
When we go to create application #4, we have to deal with an entity
that carries a lot of baggage that has nothing to do with the
common, reusable aspect of the entity. By the time we've created a
suite of 20 applications, entity A is a huge, ugly mess to deal
with. This is obviously a degenerative example, but I've seen it
happen gradually, bit by bit, and by the time someone realizes
what's happening it's too late and requires lots of refactoring.
My suggestion is to keep the use case specific logic in session
beans. Each application will have one or more session beans that
provide the business logic for that application's use cases. If
multiple applications share use cases, that business logic can be
factored out to shared session beans, or to strategy objects to
which the application session beans delegate. The business logic
can also be layered so that multiple application session beans
can share it. These are all pretty standard techniques for
functional decomposition (which still has its place even in an
object oriented system ;-).
Again, the *only* business logic that I would migrate to entity
beans is logic that is intrinsic to that entity alone, is
independent of any specific use case, and is shared by all
applications that may use the entity.
> Entity beans were not designed merely for object persistence, and there
> are better approaches for that. They were designed to put some business
> methods on top of your data objects.
I'm curious, do you have a reference that states that entity
beans were designed for more than distributed object persistence?
I'm sure there's something there, but I was only able to find
these:
The EJB 1.1 spec, section 8.1, says "an entity bean is a component
that represents an object-oriented view of some entities stored in
a persistent storage, such as a database, or entities that are
implemented by an existing enterprise application."
The Sun BluePrints Design Guidelines for J2EE, section 5.3, says
"An entity bean represents an object view of a business entity
stored in persistent storage or an existing application. The bean
provides an object wrapper around the data to simplify the task of
accessing and manipulating it. This object interface to the data
lends itself to software reuse. For example, a bean representing
user account information can be used by order management, user
personalization, and marketing in a uniform way."
The EJB spec is mostly focused on the mechanics of how entity
beans work, and doesn't get into how to use them much. The SBDG,
however, does get into the use of entity beans and it doesn't
talk about using them beyond data access.
-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".
