Adena,
You will probably get several different answers to this, and there
really isn't any one "right" answer. Because Entity Beans have a
certain degree of overhead associated with them, you don't want to make
everything in your system an Entity Bean. You want to minimize their
usage, but utilize them where it makes sense. This will also help keep
your system from being overly (and unnecessarily) complex. We look at
two basic criteria to decide what we should or shouldn't make an Entity
Bean. First we look at whether the object has meaning on its own, or
whether it only makes sense in relation to other objects in the system.
Second, we look at whether the object is "significant"; is it a complex
object which is critical to the functioning of the system? Admittedly,
these are subjective calls, but it gives us some sort of guide at least.
So here's the way that I would look at your scenario:
You have five different objects that you have identified in your system,
namely teachers, classes, credentials, requirements, and skills. By the
very definition of what you are trying to do ("I'm creating a system
which is going to assign teachers to classes"), teachers and classes are
essential pieces of the system; take away either one and you take away
the very need for the system. As vital entities in the system, I would
probably make them Entity Beans. Credentials are defining attributes of
a teacher, in that each teacher possesses certain credentials. A
credential doesn't really mean much by itself; it only has meaning in
relation to teachers (as further evidence of this, notice that your
definition of the Credential object includes a teacher ID). Thus, I
would probably make Credential a dependent object of the Teacher Entity
Bean. You can apply a similar argument to the relationship between
Requirements and Classes. As far as skills go, it sounds from the way
you have described it that skills are very simple objects used to define
credentials and requirements, so I would say that you have it right to
make them basic objects and not promote them to EJBs.
With this design in mind, I think that your SessionBean would have an
addCredential() method that took only two parameters: the teacher ID and
the credential object. The Session Bean would look up the teacher
object and call an addCreditial() method on it, passing the credential
object. As far as updateCredential() goes, I would have the SessionBean
pass the updated credential to the Teacher Entity Bean, and let the
Teacher EB do the delete/update (or just update the existing credential
object in its set of credentials with the data from the new one passed
in); that way the specifics of how to update a teacher's credentials are
encapsulated within the teacher class itself.
In answer to your fourth question, I see no problem with simply passing
back the teacher ID. One thing that we have done in our architecture is
to have all of our Entity Bean classes inherit from a "lite" version of
the class. In your case, you might have a class called TeacherLite
which encapsulates the very basic and most frequently used information
about a teacher (ID and name, for example), and from which your EB class
inherits and adds additional information such as the set of credentials,
etc. Then, you can pass around your TeacherLite object; this gives you
a little more flexibility than just passing around the ID, but is less
overhead than passing around the whole object.
Hope some of this is of use to you!
Dale
================================
Dale V. Georg
Technical Manager
Indus Consultancy Services
[EMAIL PROTECTED]
(201) 261-3100 x229
================================
Adena Galinsky wrote:
>
> This looks like a lot of text, but it's really a simple problem of 4
> questions with (hopefully) simple answers. In advance, I sincerely thank
> everyone who takes the time to read and answer.
> ******************************************
>
> Let's say I'm creating a system which is going to assign teachers to classes
> across a school district. Each school has a number of classes and each
> class has a couple teachers.
>
> Let's say there's a set of skills we look at: math-ed, phys-ed, reading-ed
> etc.
> Each teacher has a set of CREDENTIALS: where a credential is a skillID, a
> teacherID, and a couple other attributes.
> Each class has a set of REQUIREMENTS: where a requirement is a skillID, a
> classID, and a couple other attributes.
>
> Right now, we're using
> a bean to represent the CREDENTIAL,
> a bean to represent the REQUIREMENT, and
> a plain old java class to represent the SKILL.
>
> QUESTION 1:
> On the one hand, skill is shared, so you might think that skill should be a
> bean. On the other hand, skill is a pretty simple object. Should skill be a
> bean?
>
> QUESTION 2:
> On the one hand, credentials and requirements will be used later on, in a
> session bean, in the course of assigning teachers to classes. Thus they
> should be beans. However, they themselves are very simple objects. By this
> reasoning they should be plain java classes.
>
> QUESTION 3:
> Also, what interface would be the best, design-wise, for managing a
> teacher's credentials and a class's requirements? Is this right:
>
> CredentialManager SessionBean:
> addCredential(teacherID, skillID, ..<other attributes>..)
> calls Teacher Entity Bean's addCredential() method
> updateCredential(teacherID, skillID, ..<other attributes>..)
> calls Teacher Entity Bean's removeCredential() method
> THEN the Teacher Entity Bean's addCredential() method
>
> Teacher EntityBean:
> addCredential(skillID, ...<other attributes>...)
> removeCredential(skillID, ...<other attributes>...)
>
> ps
> QUESTION 4:
> Should the client not pass back the teacherID in cases like these, but
> rather pass back the entire teacher object? That seems like a waste to me,
> but perhaps that's the standard way to do things?
>
> ===========================================================================
> 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".
