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".
