A couple of questions about efdesigner HOT 5 CLOSED

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?

from efdesigner.

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.

from efdesigner.

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.

from efdesigner.

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

Thanks.

from efdesigner.

@msawczyn hey. yes you did and thank you.

from efdesigner.