Just so I understand this correctly- in the object layer, I'd have a third class called WorkInfo with methods such as .getEmployee(), .getProject(), and .getHours()? and both Employee and Project would have .getWorkInfo() that would return a collection of WorkInfo objects?
Yes, that's the basic idea: you express the relationship explicitly as an entity.
You could also try to keep the original indirection table between Emplyoee and Project in place, and then map a class to this very indirection table but this may lead to problems with the primary key of this additional class (which probably needs to be database-generated). The benefit would be that it's faster to navigate between Employee and Project.
That is a possible solution... So I suppose a HashMap or Hashtable structure would be impossible? (What *is* ManageableHashMap used for, anyway?)
Don't know exactly (never used that one), but I guess you can specify it as the collection-class, though what happens with the keys I have no idea. But you shouldn't use hashtables for your purpose, simply because of what happens when you require an additional attribute of the relation ...
Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
