This question is locked. New answers and comments are not allowed.
Hello All!
I have 2 [Persistent] classes. MyClass1 and MyClass2
In one MyClass2 can be only one MyClass1. But in MyClass1 can be a list of MyClass2
What construction is more correct?
01.[Persistent] 02.public MyClass1 03.{ 04. IList<MyClass2> myClass2List {get; set;}05.} 06. 07.[Persistent] 08.public MyClass2 09.{ 10. 11.}In this construction will be created additional table in DB [MyClass1_MyClass2]
or this construction
01.[Persistent] 02.public MyClass1 03.{ 04. 05.} 06. 07.[Persistent] 08.public MyClass2 09.{ 10. MyClass1 myClass1 {get; set;} 11.}What soluthion is more correctly?
Is it good practice to use this additional table [MyClass1_MyClass2] ?
Thanks all!
1 Answer, 1 is accepted
0
IT-Als
Top achievements
Rank 1
Rank 1
answered on 06 Oct 2010, 12:54 PM
Hi Andrey,
I think it depends on the nature of the relationship between the classes.
In the first case you line up, it seems like a join table to hold the 1:m association is created by OA. But this is only really necessary if the many side class (here MyClass2) can be referenced by other classes than MyClass1.
In general:
If there's a strong relationship between classes in a 1:m association (for example Order->OrderLines) I tend to use 1:m without a join table (using an inverse field in the many side class).
However, if the many side class can be referenced as a many side in another 1:m association with another class say Invoice->OrderLines and it really is the same instance of the OrderLine class that is referenced from both the Order and the Invoice,,, I would go for the 1:m with a join table solution, because the same instance of OrderLine can not be "owned" by two different classes.
So, bottom line is: If there's an "owner" like relationship (strong) use 1:m (without join table) if the many side can be referenced by multiple classes use the 1:m (with a join table)
In the case you line up I would go for 1:m without a join table and navigable in both directions. That is you have a list in MyClass1 of MyClass2 instances and a field in MyClass2 (the inverse field of the 1:m association) pointing back the the "owner" MyClass1
Hope this makes sense?
Regards
Henrik
I think it depends on the nature of the relationship between the classes.
In the first case you line up, it seems like a join table to hold the 1:m association is created by OA. But this is only really necessary if the many side class (here MyClass2) can be referenced by other classes than MyClass1.
In general:
If there's a strong relationship between classes in a 1:m association (for example Order->OrderLines) I tend to use 1:m without a join table (using an inverse field in the many side class).
However, if the many side class can be referenced as a many side in another 1:m association with another class say Invoice->OrderLines and it really is the same instance of the OrderLine class that is referenced from both the Order and the Invoice,,, I would go for the 1:m with a join table solution, because the same instance of OrderLine can not be "owned" by two different classes.
So, bottom line is: If there's an "owner" like relationship (strong) use 1:m (without join table) if the many side can be referenced by multiple classes use the 1:m (with a join table)
In the case you line up I would go for 1:m without a join table and navigable in both directions. That is you have a list in MyClass1 of MyClass2 instances and a field in MyClass2 (the inverse field of the 1:m association) pointing back the the "owner" MyClass1
Hope this makes sense?
Regards
Henrik