Skip to content
This repository has been archived by the owner on Jan 16, 2024. It is now read-only.

A couple of questions #8

Closed
scharada opened this issue Jun 11, 2018 · 5 comments
Closed

A couple of questions #8

scharada opened this issue Jun 11, 2018 · 5 comments
Labels
question Requesting information

Comments

@scharada
Copy link

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 ?

@msawczyn
Copy link
Owner

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 OnModelCreatingImpl partial method.

Does that help?

@scharada
Copy link
Author

Hi. i am using EF core and according to this doc it does support it.
http://www.entityframeworktutorial.net/efcore/configure-many-to-many-relationship-in-ef-core.aspx
in fact EF6 and other generators do exactly what the doc suggests to do manually.

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.

@msawczyn
Copy link
Owner

msawczyn commented Jun 12, 2018

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:

In the Entity Framework 6.x or prior, EF API used to create the joining table for many-to-many relationships. We need not to create a joining entity for a joining table (however, we can of course create a joining entity explicitly in EF 6).

In Entity Framework Core, this has not been implemented yet.

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.

@msawczyn
Copy link
Owner

@scharada , did I answer your question/concern? If so, is it ok with you to close this issue?

Thanks.

@scharada
Copy link
Author

@msawczyn hey. yes you did and thank you.

@msawczyn msawczyn added the question Requesting information label Sep 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Requesting information
Projects
None yet
Development

No branches or pull requests

2 participants