Adena Galinsky wrote:
>
> 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)
Yes, this is pretty much the way that I would handle it.
> 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?
The lite classes are "regular" Java classes. In your case, you might
define something like the following:
1) TeacherLite, a Java class with attributes for ID, name, and other
basic info;
2) TeacherBean, a Java class which extends TeacherLite, implements
EntityBean, and adds attributes such as a Vector of Credentials;
3) TeacherHome, the home interface for TeacherBean; and
4) Teacher, the remote interface for TeacherBean.
Dependent classes aren't eliminated by the use of the lite class
(Credential is a dependent class). So where do you benefit? Say that
you want to present a list of teachers to the user for selection. You
could do a find to locate all of the TeacherBeans and return a Vector of
Teacher to the client. But doing this will incur a large overhead,
particularly since every method call on the Teacher interface will a) be
a remote method call to the server, and b) cause ejbLoad() and
ejbStore() to be called. So what you can do instead is put a method on
your Session Bean called, for example, getTeacherList() which returns a
Vector of TeacherLite which the Session Bean extracts directly from the
database. This is very low overhead, and the user can be presented with
a quick list of the teachers; if they select a particular teacher and
want to view that teacher's credentials, you then pass the TeacherLite
object to the getCredentials() method of the Session Bean, and the
Session Bean can use the lite object to look up the Teacher Entity Bean
and get the additional information.
One thing to consider with this approach is how and where to write your
database code. If you are using CMP for your Entity Beans, then
admittedly you have some extra work to do in writing the code to fetch
the lite objects from the database, and you'll need to evaluate whether
it's worth it in your scenario. If you are using BMP, then you're
writing all the database access code yourself anyway, and you can
encapsulate the code in "helper" classes that are used by both the
Session Bean and the Entity Bean in order to avoid writing duplicate
code.
Again, this is just the approach that we have taken, but we have found
it to be a very workable solution. Your mileage may vary. :)
Dale
================================
Dale V. Georg
Technical Manager
Indus Consultancy Services
[EMAIL PROTECTED]
(201) 261-3100 x229
================================
===========================================================================
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".
