5
When we have two entities related to Many-to-Many and create the navigation properties correctly Entity creates an extra table to configure that relationship.
In the case I’m working I have a structure that in the best of worlds would look like this:
public class User {
public string Name {get;set}
public int id
}
public class Forum {
public string Title {get;set}
public virtual ICollection<User> Participants {get;set}
public virtual ICollection<User> Followers {get;set}
}
The problem here is precisely because it has two properties of the User type. Entity will try to store everything in the same table, and will create two foreign keys in User.
What is good practice in this case? It would create two different entities (Participants and Followers) and save User and Forum ids in each of them?
First of all, beware of restricted words, "User" for example usually gives error because it is used internally by EF if I am not mistaken. Try to be the most specific, use your system. In your case, both 'Participants' and 'Followers' are 'User', so I ask, how to know who is who? In my view you have two options, create specializations so that 'Participant' and 'Followers' inherit 'User'. Or create a new property in 'User' to save the type of user, an Enum of type 'Usertype' already serveria, where you point out if it is 'Participant' or 'Follower'.
– petersonfortes
@Stefanosandes , is using code first?
– Vinícius
Yes @Vinicius, code first.
– Stefano Sandes
@petersonfortes understood your idea. The question is, when it comes to object orientation, two collections of the same type are easily distinguished, but in BD, how do you adjust Entity to map this to two tables? I can create two specialized classes as you said yes, but it seems to me that I would be thinking in a recurtional way, not OO. As for typing, it would make no sense in a large application where references can be in many entities. Thank you very much!
– Stefano Sandes
@Stefano Sandes as far as I understand object orientation in a database is myth, the idea is very old, but in practice it doesn’t exist. Unfortunately the Entity Framework can not magically solve this kind of thing for you, the solution is to change your EDMX in hand, even so this is a mess because whenever there is a change in the bank and you have to update your EDMX, you will have to redo these manual changes. Using some logic in your business layer in my opinion is the best solution, for this case.
– petersonfortes
I understood @petersonfortes. I was hoping there was a way to set you up for this. I have worked with database-first and managed to make Nhibernate understand this type of relationship. Thank you very much!
– Stefano Sandes
@Stefano Sandes I’m currently working with Nhibernate too and it’s beautiful. I don’t miss EF at all.
– petersonfortes