Adena Galinsky wrote:
> Is it acceptable to create entity beans which subclass other (non-ejb)
> classes?
Yes. As long as they fulfill the bean contract.
>
>
> So, for example, we would have
>
> public class Person {
> public Person(String name)
> {
> ...
> }
> public String getName(){
> return name;
> }
>
> public void setName(String name) {
> this.name = name;
> }
> }
>
> public class ContactBean extends Person implements EntityBean {
> public ContactKey ejbCreate(String name, int age, String phonenumber)
> {
> ...
> }
> }
>
> public class EmployeeBean extends Person implements EntityBean {
> public EmployeeKey ejbCreate(String name, String position)
> {
> ...
> }
> }
>
> That way we wouldn't have to rewrite the person methods in both the employee
> and the contact classes
> Or would it be better to make Person a bean, and make it a property of both
> the contact and employee classes?
This could get tricky and is dependent on how you map the data to the underlying
database.
>
> Or woudl it be better to just make person an interface and implement it in
> both the contact and employee classes?
>
Duplicate implementations should only be used as a last resort. You can use
composition as in the previous option, but without Person being an entity bean.
There's another option. If Contact and Employee use the same primary key class
(and by implication use a common set of primary keys), you could have Person
implement a large portion of the bean methods. You can override/overload create
and finder methods and only put the appropriate ones in the respective Contract
and Employee interfaces.
--Victor Langelo
===========================================================================
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".
