Entity First One-to-One Structure Code Required Relationships

Question

When using the Entity Framework Code First 4.3.1, you can create relationships with a plurality of 1 to 1. That is, one entity at each end of the relationship.

You can configure the 1-to-1 relationship required-required or required-optional ^. However, when I switch between them, I see no differences in:

• Database schema created. I am targeting SQL Server 2008.
• EF runtime

That way, I can create a RequiredPrincipalAs entry without the corresponding RequiredDependentAs entry, even though the relationship has been configured as required . This seems to contradict the documentation for HasRequired (...) :

Configures the required association with this type of object. Entity type instances cannot be stored in the database unless this relationship is specified. The foreign key in the database will be invalid.

http://msdn.microsoft.com/en-us/library/gg671317

required relationship:

public class RequiredPrincipalA { public int Id { get; set; } public virtual RequiredDependentA DependentA { get; set; } } public class RequiredDependentA { public int Id { get; set; } public virtual RequiredPrincipalA PrincipalA { get; set; } } 

Objects of the relationship are required-optional :

 public class RequiredPrincipalB { public int Id { get; set; } public virtual OptionalDependentB DependentB { get; set; } } public class OptionalDependentB { public int Id { get; set; } public virtual RequiredPrincipalB PrincipalB { get; set; } } 

DbContext configuration and models:

 public class AppContext : DbContext { public DbSet<RequiredPrincipalA> PrincipalAs { get; set; } public DbSet<RequiredDependentA> DependentAs { get; set; } public DbSet<RequiredPrincipalB> PrincipalBs { get; set; } public DbSet<OptionalDependentB> DependentBs { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Entity<RequiredPrincipalA>() .HasRequired(o => o.DependentA) .WithRequiredPrincipal(o => o.PrincipalA); modelBuilder.Entity<RequiredPrincipalB>() .HasOptional(o => o.DependentB) .WithRequired(o => o.PrincipalB); } } 

Security Code:

 Database.SetInitializer(new DropCreateDatabaseAlways<AppContext>()); using (var ctx = new AppContext()) { ctx.Database.Initialize(force: false); ctx.PrincipalAs.Add(new RequiredPrincipalA()); ctx.PrincipalBs.Add(new RequiredPrincipalB()); ctx.SaveChanges(); } 

I know that I could add the [Required] data attribute for the RequiredPrincipalA.DependentA and RequiredDependentA.PrincipalA navigation properties. This will cause EF checking to prevent the above scenario. However, I do not want to do this because it also checks that the navigation property is populated when updating an existing object. This means that the application must first obtain an object at the other end of the relationship for each update.

Why can't I see the difference in EF behavior only when the relationship between mandatory and mandatory-optional changes?

^ Please note that optional-optional is also supported, but this is not part of my question. There are obvious differences in the generated database schema and runtime when an optional-optional relationship is configured.

Answer 1

I do not know why the required-necessary is allowed for this case, but it cannot exist in the database, because the relationship is built on primary keys. Mandatory-obligatory means that A cannot be inserted if a related B does not exist and B cannot be inserted if a related A does not exist => neither A nor B. can be inserted.

A database relation always has a main and dependent entity - a principle can always exist without dependence.

The actual required, required in EF, can be achieved only when both A and B are mapped to the same table (table partition ), because in this case they are both inserted with the same insert command.

Answer 2

Not quite an answer, but I need to say more than in the comments. But you know, I write 900 pages of books ... it's just how I roll. :)

Oddly enough, I would expect a smooth configuration to behave the same as a data annotation, and I'm confused that it does not. (I pinged Rowan Miller with a link to this topic to get his feedback.) And I mean the following: checking the constraint during SaveChanges.

On the database side, I'm with Ladislav. In the model, EF defines 1: 1 using the keys of related objects. But in the database, you cannot have FK in both tables, so only the dependent table in the database will require the constraint that PK maps to the existing PK in the main table.

And finally, I understand your reason that you do not want EF to enforce the relationship if you are not going to always deal with the full schedule. I think 1: 1 relationships are the most confusing for EF relationship comparisons, and I always have to come back for reminders of the rules and how things should work.