Dale,
Thanks so much for your answer.
Let me see if I understand you correctly:
Skill, Credential, and Requirement should all be basic java classes, not
beans.
Credential and Requirement no longer include the teacherID as an attribute
SessionBean methods:
getCredentials(TeacherKey teacherKey)
1. finds teacher by primary key using TeacherHome
2. calls teacher.getCredentials()
addCredential(TeacherKey teacherKey, Credential credential)
1. finds teacher by primary key using TeacherHome
2. calls teacher.addCredential(credential)
updateCredential(TeacherKey teacherKey, Credential credential)
1. finds teacher by primary key using TeacherHome
2. calls teacher.updateCredential(credential)
I find your TeacherLite idea very intreiguing. Are you "Lite" classes beans
themselves,
or regular java objects? And do you use data classes and dependent classes,
or do "Lite" classes eliminate the need for such things?
Adena
****************************************************************
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".
===========================================================================
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".
