Best approach to manage bidirectional relations

[rvazquez]

Which is the best approach to manage bidirectional relationships ? I mean, you can manage them in the EntityHome class or let the EntityBean take care of that.

May be it´s not necessary, but an example would be:

Bidirectional optional OneToOne
A may have one B, B may have one A

A (0,1) <--> (0,1) B

1) The EntityHome class does the job

class AHome extends EntityHome<A>

   persist(){
     //a.setB(b); //data binding does this
     a.getB().setA(this.getInstance()); // set relation from B to A
   }

   update()...

   remove()....

}

2) The EntityBean does the job

@Entity
class A {
    ...............
     setB(B b){
             //if b has changed
             if(this.b != null && this.b != b){
                   this.b.setA(null);            //unlink old B to A
             }
             this.b = b;
     }
    ...............
}

We are very interested in your opinion based on design best practices, but also considering our particular situation.

In our case we are developing a code generator which generate Seam applications, based on EntityBeans. So, if we can avoid to force the user to code relations management in EntityBeans it would be a nice feature. The problem here is which is the best idea to get the previous value of A.b, when you update b, in order to make the comparsion between old and new value and then work whith old object if it is necessary.

Thanks in advance.

Rodolfo

http://www.jgenui.org/joomla

[gaborj]

1. One point is to separate the model from business logic, so that you can refactor your tables and model beans with minimal impact on BL.


2. The other way e.g. you do not define Foreign Keys in DB and/or dependencies in your entities then they are loosely coupled but actually your model dependencies are coded in your BL tier, and your table dependencies are hidden in the Model tier which is not safe in most cases.

To clear up things: in current implementation both of these (and much more) are possible, user is never forced to go with 1.

In your example use case this is some kind of validation. In most cases validation is in close relation to the Model field values and the implementation can be easily covered by Hibernate Validator. There are exceptional cases when validation is more complex and rather part of BL, I experience such almost in each project, then I usually follow the old proven Transfer Object/Value Object pattern, but I think this is the exception here. So, I would follow 1.

[rvazquez]

Gabor,
Thank you very much for your reply.