You're liable to get a different opinion from every respondant, but here's how
we're feeling our way through it.
1. Any persistent class that can reasonably be expected to become an "entry
point" into the system is a strong candidate for entity bean status. These
often end up being domain concepts such as Customer, Employee, Order, etc.
2. Look at the relationships from those classes. If a related class exists in a
composite role to the parent, then is almost certainly does not need to be an
entity bean. Examples might include Order Line Items, Employee Phone Numbers,
etc. If the class in question relates as an aggregate, then refer back to #1.
When in doubt, we've err'ed on the side of being stingy with entity beans --
simply because there's more work involved in developing a new entity bean and we
operate on the "simplest way that could work" principle.
3. Regarding business logic in entity beans vs. session beans: You'll read a lot
of literature that encourages entity beans as relatively dumb data objects.
We've struggled with how to draw the line, but in general, we try to put as much
intelligence within an entity bean as possible -- as long as the logic operates
within the scope of the bean. It naturally follows that having fewer, richer
entity beans with supporting, "owned" persistent classes allows for richer
functionality within the bean -- because the "within the scope of the bean" rule
becomes less restrictive. Nevertheless, we have significant amounts of
cross-bean business logic session beans as well.
To summarize our approach:
a. Fewer, richer entity beans
b. Business login in the entity bean if possible
c. Cross entity-bean logic in session beans
I should note that this is all made possible (practicle) because we are using a
powerful CMP tool (TopLink for WebLogic) that makes item (a) a snap.
Tom Larson
-----Original Message-----
From: Uday Rajgir <[EMAIL PROTECTED]>
Sent: Thursday, March 23, 2000 2:09 AM
To: [EMAIL PROTECTED]
Subject: How to derive Beans from Classes?
I am a analyst working with designing OO systems for the past couple of years. I
am in the process of designing a system where we want to use EJB and Servlets.
This is my first project where we will be designing using EJB's.
My question is on what basis do I decide which classes to convert to EJB -
either Session or Entity Beans.
On the initial study of this system we have come up with around 55 classes - its
an accounting system. All the classes are persistent classes. Now if my
understanding is correct I just simply cannot take all these classes and convert
them to Entity Beans,
I think I am missing understanding a key thing in EJB and am not able to place a
handle on that. Any idea as to how should I proceed with identifying Entity and
Session Beans. Is there a rule of thumb?
===========================================================================
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".
===========================================================================
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".
