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?
c# .net entity-framework ef-core-2.1
|
show 5 more comments
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?
c# .net entity-framework ef-core-2.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 haveone
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 aCar
(CardId). And to determine which actual tyre the wheel is one may also imagine it having aPosition
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: egcar.Wheels.Front();
orcar.Wheels.FrontLeft();
– JohnB
Nov 20 at 0:31
|
show 5 more comments
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?
c# .net entity-framework ef-core-2.1
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
c# .net entity-framework ef-core-2.1
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 haveone
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 aCar
(CardId). And to determine which actual tyre the wheel is one may also imagine it having aPosition
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: egcar.Wheels.Front();
orcar.Wheels.FrontLeft();
– JohnB
Nov 20 at 0:31
|
show 5 more comments
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 haveone
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 aCar
(CardId). And to determine which actual tyre the wheel is one may also imagine it having aPosition
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: egcar.Wheels.Front();
orcar.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
|
show 5 more comments
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 aPosition
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();
orcar.Wheels.FrontLeft();
– JohnB
Nov 20 at 0:31