I recently came by the class ManyNavigationPropertyConfiguration<TEntity, TTarget>
, and within that class there I found a method named WithMany()
with 2 overloads.
The first overload:
WithMany()
Configures the relationship to be many:many without a navigation property on the other side of the relationship.
The second overload:
WithMany(Expression<Func<TTarget, ICollection<TEntity>>>)
Configures the relationship to be many:many with a navigation property on the other side of the relationship.
Now is my question, why would you configure a relationship to be many:many without a navigation property (the first overload)? I dont see any scenarios where that would be helpful... Any thoughts?
Note that the choice for a navigation property is on the other side of the target.
Let's look at an example, even though this specific case might not be the perfect illustrator of my point... If you want to keep track of math tests, and re-use questions, you might have two tables (
Tests
andQuestions
) which have a many-to-many relationship; each test has several questions, and each question can appear on several tests. However, you might not ever need to get a collection of tests that a specific question is on - even though you know that questions can appear on more than one test, you aren't interested in which.Thus, you use the
.WithMany()
overload when declaring this, so you get a navigational property to get the questions of a test (theTest.Questions()
) but no navigational property the other way (theQuestion.Tests()
). But you still need a many-to-many relationship, since both tests and questions can have many of the other.I agree that in this specific case this setup might not make sense, but there is certainly cases where it does, and in those cases the
.WithMany()
overload lets you get by without defining properties (and a lambda expression for each one of them) you'll never need.An example might be this model:
If you are never interested to retrieve all users which are in a specific role, adding a navigation property ...
... to the
Role
class would be unnecessary overhead.But you still must EF tell that a many-to-many relationship between
User
andRole
exists ...... because the default convention mappings would create a wrong relationship, namely a one-to-many relationship, corresponding to this mapping: