EF Core - Creating two navigation properties mapped to a single inverse property











up vote
0
down vote

favorite












I have the following entities set up.



public class Car
{
public int Id { get; protected set; }
public HashSet<Wheel> FrontWheels { get; set; };
public HashSet<Wheel> RearWheels { get; set; };
}

public class Wheel
{
public int Id { get; protected set; }
//public Car Car { get; set; }
public double Diameter { get; set; }
public double Width { get; set; }
}


A Car has Wheels. It interacts with the fronts and rears very differently and therefore they are held in different collections. A wheel by itself is neither a front or a rear (it could be either), it is only through its association with the car that it is given a position on the car.



I can set this up in EF Core 2.1 using the following config:



    modelBuilder.Entity<Car>().HasMany(car => car.FrontWheels).WithOne();
modelBuilder.Entity<Car>().HasMany(car => car.RearWheels).WithOne();


This creates a Wheel table with two nullable fk columns, CarIdFrontWheel & CarIdRearWheel. I understand why it creates two columns and why they're nullable (only 1 fk column will be populated for each Wheel row, and that column describes the position on the car). This schema describes the situation and I am happy with that.



Now the problem starts when I want to add back in the commented out inverse navigation property - so that I can navigate from a Wheel to it's connected Car. However I configure it, EF always wants to add another fk named CarId to the Wheel table to map back to a Car. I understand why it needs to do this - Otherwise I'm attempting to ask one property (Wheel.Car) to partake in two relationships. Both fks could point to a different Car id, etc.



However, what I am asking seems logically reasonable from an entity relationship point of view. If we were writing this data access manually, we could make the schema work without this unnecessary (somewhat de-normalized) 3rd foreign key.




  • Is this possible to configure these entities using just the two
    (CarIdFrontWheel & CarIdRearWheel) foreign keys?

  • Should I instead just accept the existence of the CarId foreign key?

  • Or, are there some changes I can make to my model to help this situation?










share|improve this question


















  • 1




    i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have one collection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
    – JohnB
    Nov 20 at 0:16








  • 1




    the Wheel class can have a nav property back to a Car (CardId). And to determine which actual tyre the wheel is one may also imagine it having a Position Property (Front-Left) or similar...
    – JohnB
    Nov 20 at 0:21






  • 1




    EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
    – Ivan Stoev
    Nov 20 at 0:25






  • 1




    Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
    – JohnB
    Nov 20 at 0:28






  • 1




    also think about how developers will need to access data: eg car.Wheels.Front(); or car.Wheels.FrontLeft();
    – JohnB
    Nov 20 at 0:31















up vote
0
down vote

favorite












I have the following entities set up.



public class Car
{
public int Id { get; protected set; }
public HashSet<Wheel> FrontWheels { get; set; };
public HashSet<Wheel> RearWheels { get; set; };
}

public class Wheel
{
public int Id { get; protected set; }
//public Car Car { get; set; }
public double Diameter { get; set; }
public double Width { get; set; }
}


A Car has Wheels. It interacts with the fronts and rears very differently and therefore they are held in different collections. A wheel by itself is neither a front or a rear (it could be either), it is only through its association with the car that it is given a position on the car.



I can set this up in EF Core 2.1 using the following config:



    modelBuilder.Entity<Car>().HasMany(car => car.FrontWheels).WithOne();
modelBuilder.Entity<Car>().HasMany(car => car.RearWheels).WithOne();


This creates a Wheel table with two nullable fk columns, CarIdFrontWheel & CarIdRearWheel. I understand why it creates two columns and why they're nullable (only 1 fk column will be populated for each Wheel row, and that column describes the position on the car). This schema describes the situation and I am happy with that.



Now the problem starts when I want to add back in the commented out inverse navigation property - so that I can navigate from a Wheel to it's connected Car. However I configure it, EF always wants to add another fk named CarId to the Wheel table to map back to a Car. I understand why it needs to do this - Otherwise I'm attempting to ask one property (Wheel.Car) to partake in two relationships. Both fks could point to a different Car id, etc.



However, what I am asking seems logically reasonable from an entity relationship point of view. If we were writing this data access manually, we could make the schema work without this unnecessary (somewhat de-normalized) 3rd foreign key.




  • Is this possible to configure these entities using just the two
    (CarIdFrontWheel & CarIdRearWheel) foreign keys?

  • Should I instead just accept the existence of the CarId foreign key?

  • Or, are there some changes I can make to my model to help this situation?










share|improve this question


















  • 1




    i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have one collection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
    – JohnB
    Nov 20 at 0:16








  • 1




    the Wheel class can have a nav property back to a Car (CardId). And to determine which actual tyre the wheel is one may also imagine it having a Position Property (Front-Left) or similar...
    – JohnB
    Nov 20 at 0:21






  • 1




    EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
    – Ivan Stoev
    Nov 20 at 0:25






  • 1




    Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
    – JohnB
    Nov 20 at 0:28






  • 1




    also think about how developers will need to access data: eg car.Wheels.Front(); or car.Wheels.FrontLeft();
    – JohnB
    Nov 20 at 0:31













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I have the following entities set up.



public class Car
{
public int Id { get; protected set; }
public HashSet<Wheel> FrontWheels { get; set; };
public HashSet<Wheel> RearWheels { get; set; };
}

public class Wheel
{
public int Id { get; protected set; }
//public Car Car { get; set; }
public double Diameter { get; set; }
public double Width { get; set; }
}


A Car has Wheels. It interacts with the fronts and rears very differently and therefore they are held in different collections. A wheel by itself is neither a front or a rear (it could be either), it is only through its association with the car that it is given a position on the car.



I can set this up in EF Core 2.1 using the following config:



    modelBuilder.Entity<Car>().HasMany(car => car.FrontWheels).WithOne();
modelBuilder.Entity<Car>().HasMany(car => car.RearWheels).WithOne();


This creates a Wheel table with two nullable fk columns, CarIdFrontWheel & CarIdRearWheel. I understand why it creates two columns and why they're nullable (only 1 fk column will be populated for each Wheel row, and that column describes the position on the car). This schema describes the situation and I am happy with that.



Now the problem starts when I want to add back in the commented out inverse navigation property - so that I can navigate from a Wheel to it's connected Car. However I configure it, EF always wants to add another fk named CarId to the Wheel table to map back to a Car. I understand why it needs to do this - Otherwise I'm attempting to ask one property (Wheel.Car) to partake in two relationships. Both fks could point to a different Car id, etc.



However, what I am asking seems logically reasonable from an entity relationship point of view. If we were writing this data access manually, we could make the schema work without this unnecessary (somewhat de-normalized) 3rd foreign key.




  • Is this possible to configure these entities using just the two
    (CarIdFrontWheel & CarIdRearWheel) foreign keys?

  • Should I instead just accept the existence of the CarId foreign key?

  • Or, are there some changes I can make to my model to help this situation?










share|improve this question













I have the following entities set up.



public class Car
{
public int Id { get; protected set; }
public HashSet<Wheel> FrontWheels { get; set; };
public HashSet<Wheel> RearWheels { get; set; };
}

public class Wheel
{
public int Id { get; protected set; }
//public Car Car { get; set; }
public double Diameter { get; set; }
public double Width { get; set; }
}


A Car has Wheels. It interacts with the fronts and rears very differently and therefore they are held in different collections. A wheel by itself is neither a front or a rear (it could be either), it is only through its association with the car that it is given a position on the car.



I can set this up in EF Core 2.1 using the following config:



    modelBuilder.Entity<Car>().HasMany(car => car.FrontWheels).WithOne();
modelBuilder.Entity<Car>().HasMany(car => car.RearWheels).WithOne();


This creates a Wheel table with two nullable fk columns, CarIdFrontWheel & CarIdRearWheel. I understand why it creates two columns and why they're nullable (only 1 fk column will be populated for each Wheel row, and that column describes the position on the car). This schema describes the situation and I am happy with that.



Now the problem starts when I want to add back in the commented out inverse navigation property - so that I can navigate from a Wheel to it's connected Car. However I configure it, EF always wants to add another fk named CarId to the Wheel table to map back to a Car. I understand why it needs to do this - Otherwise I'm attempting to ask one property (Wheel.Car) to partake in two relationships. Both fks could point to a different Car id, etc.



However, what I am asking seems logically reasonable from an entity relationship point of view. If we were writing this data access manually, we could make the schema work without this unnecessary (somewhat de-normalized) 3rd foreign key.




  • Is this possible to configure these entities using just the two
    (CarIdFrontWheel & CarIdRearWheel) foreign keys?

  • Should I instead just accept the existence of the CarId foreign key?

  • Or, are there some changes I can make to my model to help this situation?







c# .net entity-framework ef-core-2.1






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 20 at 0:11









Martyn

74721126




74721126








  • 1




    i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have one collection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
    – JohnB
    Nov 20 at 0:16








  • 1




    the Wheel class can have a nav property back to a Car (CardId). And to determine which actual tyre the wheel is one may also imagine it having a Position Property (Front-Left) or similar...
    – JohnB
    Nov 20 at 0:21






  • 1




    EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
    – Ivan Stoev
    Nov 20 at 0:25






  • 1




    Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
    – JohnB
    Nov 20 at 0:28






  • 1




    also think about how developers will need to access data: eg car.Wheels.Front(); or car.Wheels.FrontLeft();
    – JohnB
    Nov 20 at 0:31














  • 1




    i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have one collection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
    – JohnB
    Nov 20 at 0:16








  • 1




    the Wheel class can have a nav property back to a Car (CardId). And to determine which actual tyre the wheel is one may also imagine it having a Position Property (Front-Left) or similar...
    – JohnB
    Nov 20 at 0:21






  • 1




    EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
    – Ivan Stoev
    Nov 20 at 0:25






  • 1




    Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
    – JohnB
    Nov 20 at 0:28






  • 1




    also think about how developers will need to access data: eg car.Wheels.Front(); or car.Wheels.FrontLeft();
    – JohnB
    Nov 20 at 0:31








1




1




i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have one collection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
– JohnB
Nov 20 at 0:16






i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have one collection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
– JohnB
Nov 20 at 0:16






1




1




the Wheel class can have a nav property back to a Car (CardId). And to determine which actual tyre the wheel is one may also imagine it having a Position Property (Front-Left) or similar...
– JohnB
Nov 20 at 0:21




the Wheel class can have a nav property back to a Car (CardId). And to determine which actual tyre the wheel is one may also imagine it having a Position Property (Front-Left) or similar...
– JohnB
Nov 20 at 0:21




1




1




EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
– Ivan Stoev
Nov 20 at 0:25




EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
– Ivan Stoev
Nov 20 at 0:25




1




1




Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
– JohnB
Nov 20 at 0:28




Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
– JohnB
Nov 20 at 0:28




1




1




also think about how developers will need to access data: eg car.Wheels.Front(); or car.Wheels.FrontLeft();
– JohnB
Nov 20 at 0:31




also think about how developers will need to access data: eg car.Wheels.Front(); or car.Wheels.FrontLeft();
– JohnB
Nov 20 at 0:31

















active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384432%2fef-core-creating-two-navigation-properties-mapped-to-a-single-inverse-property%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384432%2fef-core-creating-two-navigation-properties-mapped-to-a-single-inverse-property%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen