-
Notifications
You must be signed in to change notification settings - Fork 60
A couple of questions #8
Comments
Thanks for the compliment. 1 - A bidirectional relationship can be any supported cardinality. Many-to-many isn't supported in EF Core (yet) so can't work there, but does work in EF6. If you have an EF6 model where many-to-many relationships aren't working, please attach it to this chain and I'll be happy to take a look. 2 - If you're using table-per-hierarchy inheritance, Entity Framework will create a discriminator field for you... it isn't something you model in the normal sense. If you have a case where you have an odd need to model it yourself, it can be added in the DbContext's setup in the Does that help? |
Hi. i am using EF core and according to this doc it does support it. regarding the descriminatot field, i've been adding it manually, but would be nice to have all this in a visual tool. makes life easier. thanks for sharing. |
Apologies if I wasn't as clear as I could have been. Yes, you can mimic a many-to-many association in EF Core; in fact, the doc you cite talks about that:
So, as you've pointed out, to implement this one creates two one-to-many associations from the classes in question to a "join class" containing the identity properties of the other classes. But that's not object modeling -- it's working around a deficit in the EF Core implementation that prevents you from doing true many-to-many associations, like you would do them in EF 6. The principle behind the modeling tool is object modeling, not focusing on the database implementation. Since the implementation won't (yet) do the work it needs to do to implement that association type, there's code to restrict the ability to add a many-to-many association in the model if the type is EF Core. When EF Core evolves to the point where that's implemented, that restriction will be removed. That's not to say you can't create the artificial join class yourself ... it's just that, since it's not a true many-to-many association, the designer won't do it. (That being said, there are some convenience properties that nod to the fact that there's a database somewhere back there, like the connection string and database column name, but those don't really hurt the model.) I had kicked around the idea of creating that join class behind the scenes, but would have to take liberties in naming the tables, since I don't want their existence to be exposed to the model UI. Since most folks are picky about that, I didn't think it was a good idea. I could, however, be convinced that I was wrong. The inheritance discriminator is the same way. When modeling classes, you wouldn't add that implementation-dependent property. It's only necessary for table-per-hierarchy inheritance, and wouldn't be a property of the class if you weren't persisting it using that particular inheritance implementation. So we don't add the property automatically using the tooling, instead letting the persistence mechanism (i.e., Entity Framework) take care of it, and therefore don't pollute the classes with properties unnecessary for their purpose in life, which is supporting the application logic. As well, if it were added I wouldn't want it exposed to the model UI, so would have to force a name for the column and, like the join class, and that wouldn't be nice. Again with this, I might be overly cautious about this. It's really a philosophy thing. Hope that makes sense. |
@scharada , did I answer your question/concern? If so, is it ok with you to close this issue? Thanks. |
@msawczyn hey. yes you did and thank you. |
Hi. great work.
1 - is biderectional relationships many to many ? if that's the case, how to use it, can't get it to work.
2 - in inheritance, what's the descriminator field ? it does not seem to mention it anywhere ?
The text was updated successfully, but these errors were encountered: