a join entity instead of a shadow foreign key

[yecril71pl]

I have a situation when entity A has many entities C and entity B has many entities C too, entities A and B being different and unrelated. If I understand the description correctly, the framework will inject optional shadow foreign key for entities A and B into the property C. I would prefer to have separate join entities AhasC and BhasC in the model.

I understand that I can say "C has many A with many via A.Cs" but that reads counter-intuitive (a location has many inhabitants reads all right, but inhabitants is an abstract word coined specially for this case, so as to avoid the cringe of saying a location has many persons; the construct is by no means generic). I would expect to be able to say "A has many C with many" but that does not work because the sentence is incomplete without a collection property. But C does not have a collection property for A, nor should it have.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 24b2b50e-35f8-9e0b-8ce5-840e1ea816e6
• Version Independent ID: 9e0e6e2c-48fa-76c3-3bd9-813a6df22645
• Content: Relationships - EF Core
• Content Source: entity-framework/core/modeling/relationships.md
• Product: entity-framework
• Technology: entity-framework-core
• GitHub Login: @AndriySvyryd
• Microsoft Alias: avickers

[ajcvickers]

@yecril71pl This tracked by dotnet/efcore#3864. The workaround for now is to create a private collection navigation, or even make it a field.

[yecril71pl]

@yecril71pl This tracked by dotnet/efcore#3864. The workaround for now is to create a private collection navigation, or even make it a field.

My pain point is not visibility but the fact that I would have to add a navigation field in C for every superior that has C as a dependent. The only acceptable workaround is using an explicit association class. However, the natural candidate, a KeyValuePair, is not accepted because it is a value type (see #3604) and cannot be normally navigated because it is keyless, which is normal for an association record. It can be navigated as an owned entity but this is kinda hard to figure out because that is advanced stuff (at least in the exposition order). This problem is so severe it should at least be mentioned in the handout.

[ajcvickers]

@yecril71pl Can you share an example of C# code you want to use to define the entity types in this case?

[yecril71pl]

class Person {
    public int Id { get; set; }
    public IEnumerable < PersonAddress > Addresses { get; set; }
    …
}

class Address {
    public int Id { get; set; }
    …
}

class PersonAddress {
    public Person Person { get; set; }
    public Address Address { get; set; }
}

[ajcvickers]

@yecril71pl Supporting this shape is exactly what is covered by dotnet/efcore#3864

[yecril71pl]

I understand, I just do not approve of your workaround. I believe I have a better one.

[ajcvickers]

@yecril71pl Feel free to comment on that issue with your better workaround. People can choose to use it if they wish.

[yecril71pl]

Is #3606 (comment)
I hoped to get some feedback about how fragile/inappropriate/whatever it is. But I shall go with it FTTB and see how it goes.