1 to 1 optional Relationships with Entity Framework - entity-framework

Question

I am strugging to see why entity framework does not allow 1 to 1 relationships in the following context;
ClassA {
public int ID;
[ForeignKey("ClassB")]
public int ClassBID;
public ClassB classB;
}
ClassB {
public int ID;
[ForeignKey("ClassA")]
public int ClassAID;
public ClassA classa;
}
i.e. a one to one relationship whereby I could navigate to either from linq.
The context I have is that I have a Vehicle. Each Vehicle can have a device (which is null if it doesnt). An each device will have an optional vehicle.
If someone could explain why he above is not valid (or supported) and explain how I would get around my issue I would really apreciate it.
Thanks in advance.

Answer 1

You have to decide that one end is non-optional (i.e., 1-to-0..1 is allowed ... 0..1-to-0..1 is not). Once you do, EF supports 1-to-0..1 by forcing the dependent side to not have it's own Key, but to instead define the dependent class' Key to be the same as its ForeignKey (which, if you think about it, makes sense for a relation that's supposed to be 1-to-1):
class A
{
public int Id { get; set; }
public int? BId { get; set; }
public virtual B B { get; set; }
}
class B
{
[Key, ForeignKey("A")]
public int Id { get; set; }
public virtual A A { get; set; }
}
Note, too, the detail that BId is int?: NULL in SQL corresponds to Nullable<> in C#.

Answer 2

If I understand a device can have zero or one vehicles and vice-versa.
In an old DB model one of the two tables (device or vehicles) should have a nullable field that references the other table.
To configure it in EF you have to use data annotation or fluent interface.
Here the code of the model and of the context
public class ClassA
{
public int Id { get; set; }
public string Description { get; set; }
public virtual ClassB ClassB { get; set; }
}
public class ClassB
{
public int Id { get; set; }
public string Description { get; set; }
public virtual ClassA ClassA { get; set; }
}
class Context : DbContext
{
public Context(DbConnection connection)
: base(connection, false)
{ }
public DbSet<ClassA> As { get; set; }
public DbSet<ClassB> Bs { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<ClassB>().HasOptional(c => c.ClassA).WithOptionalDependent(c => c.ClassB);
}
}
As you can immagine there are some restrictions on using this model. I.e. the model (POCO model) allow you to have a classA1 referencing a classB1 that references classA2 (same type but different instance of classA1). The DB and EF does not. Here an example with a query dump on how EF works in this case (I think is very interesting!!!)
using (Context context = new Context(connection))
{
ClassA classA;
ClassB classB;
// Very simple behaviour (as expected). You can see the queries after SaveChanges()
classA = new ClassA {Description = "B empty"};
context.As.Add(classA);
classA = new ClassA { Description = "B full", ClassB = new ClassB(){Description = "ClassB full"}};
context.As.Add(classA);
classB = new ClassB { Description = "B empty"};
context.Bs.Add(classB);
context.SaveChanges();
/*
insert into [ClassAs]([Description])
values (#p0);
#p0 = B full
insert into [ClassAs]([Description])
values (#p0);
#p0 = B empty
insert into [ClassBs]([Description], [ClassA_Id])
values (#p0, #p1);
#p0 = ClassB full
#p1 = 1
insert into [ClassBs]([Description], [ClassA_Id])
values (#p0, null);
#p0 = B empty
*/
// Here a new classB references an already referenced classA. But we don't want this!!!
// EF works like we want, the classA is detached from the old classB then attached to the
// new classB. Below you can see the queries
classB = new ClassB { Description = "B full with the wrong A", ClassA = classA};
context.Bs.Add(classB);
/*
update [ClassBs]
set [ClassA_Id] = null
where (([Id] = #p0) and ([ClassA_Id] = #p1))
#p0 = 1
#p1 = 1
insert into [ClassBs]([Description], [ClassA_Id])
values (#p0, #p1);
#p0 = B full with the wrong A
#p1 = 1
*/
context.SaveChanges();
}
Now last step...
Looking at the structure of the database this POCO model is
ClassBs(Id, Description, ClassA_Id : ClassAs)
ClassAs(Id, Description)
In the DB model we could have 2 different instances of ClassB that has the same ClassA instance (EF does not allow us to do this but we can do this from SQL).
After the hack using SQL you can run this test
using (Context context = new Context(connection))
{
foreach (var classB in context.Bs.ToList())
{
if (classB.ClassA == null)
continue;
Console.WriteLine("{0} {1} {2}", classB.Id, classB.ClassA.Id, classB.ClassA.ClassB.Id);
}
}
This test raises an exception
===
An unhandled exception of type 'System.InvalidOperationException' occurred in EntityFramework.dll
Additional information: A relationship multiplicity constraint violation occurred: An EntityReference can have no more than one related object, but the query returned more than one related object. This is a non-recoverable error.
===
Can we avoid that someone from SQL does it? Yes, inserting a unique constraint on ClassA_Id field.