Tom,
Excellent guidelines! This one goes in my archives (except the the tool
recommendation of course ;-)
-Chris.
> -----Original Message-----
> From: Tom Larson [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 23, 2000 9:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: How to derive Beans from Classes?
>
> 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".
===========================================================================
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".
