I'm migrating a Entity Framework 6.1.3 Code First library to Entity Framework Core with C# and .NET Framework 4.7.
I've been searching about Entity Framework Core with Google but I haven't found many information about it so I have try to do it by myself.
On Entity Framework 6.1.3 I have this configuration class:
using System.Data.Entity.ModelConfiguration;
namespace MyProject.Data.SqlServer.Configurations
{
class AggregationChildrenConfiguration : EntityTypeConfiguration<AggregationChildren>
{
public AggregationChildrenConfiguration()
{
HasKey(ag_ch => ag_ch.AggregationChildrenId);
HasRequired(ag_ch => ag_ch.Aggregation)
.WithMany(ag => ag.AggregationChildren)
.HasForeignKey(ag_ch => ag_ch.AggregationId);
HasRequired(ag_ch => ag_ch.Code)
.WithOptional(c => c.AggregationChild)
.WillCascadeOnDelete(false);
}
}
}
I have migrated to this one:
using DataLibrary;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;
namespace BusinessLibrary.Configurations
{
class AggregationChildrenConfiguration : IEntityTypeConfiguration<AggregationChildren>
{
public void Configure(EntityTypeBuilder<AggregationChildren> builder)
{
builder.HasKey(ag_ch => ag_ch.AggregationChildrenId);
builder.HasRequired(ag_ch => ag_ch.Aggregation)
.WithMany(ag => ag.AggregationChildren)
.HasForeignKey(ag_ch => ag_ch.AggregationId);
builder.HasRequired(ag_ch => ag_ch.Code)
.WithOptional(c => c.AggregationChild)
.WillCascadeOnDelete(false);
}
}
}
But builder hasn't got HasRequired
method, and I think the others methods WithOptional
, WithMany
and WillCascadeOnDelete
either.
I have migrated to this, but I'm not sure if it is correct:
using DataLibrary;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;
using System;
namespace BusinessLibrary.Configurations
{
class AggregationChildrenConfiguration : IEntityTypeConfiguration<AggregationChildren>
{
public void Configure(EntityTypeBuilder<AggregationChildren> builder)
{
builder.HasKey(ag_ch => ag_ch.AggregationChildrenId);
builder.HasOne(ag_ch => ag_ch.Aggregation)
.WithMany(ag => ag.AggregationChildren)
.HasForeignKey(ag_ch => ag_ch.AggregationId)
.IsRequired();
builder.HasOne(ag_ch => ag_ch.Code)
.WithOne(c => c.AggregationChild)
.OnDelete(DeleteBehavior.SetNull);
}
I've been checking EntityTypeBuilder documentation but I don't know which methods do I have to use instead or if this is the right way to migrate to Entity Framework Core.
This relationship is not one-to-zero:
builder.HasOne(ag_ch => ag_ch.Code)
.WithOne(c => c.AggregationChild)
.OnDelete(DeleteBehavior.SetNull);
In this SO Answer said that I have to put ForeignKey to null it will set it as optional, but I can't set Code.CodeId
as nullable.
The EF6 setup is creating a so called One-To-One Shared Primary Key Association where the PK of the dependent entity is also a FK to principal entity.
The things have changed in EF Core. It supports naturally both shared PK and FK one-to-one associations. Also optional/required are not used to determine the principal and dependent ends of the association. IsRequired
is used to control if the dependent entity can exists w/o principal and applies only whith separate FK. While HasForeignKey
and HasPrincipalKey
are used to determine the principal and dependent ends of the association and also map the dependent FK and principal PK / Alternate Key.
With that being said, the equivalent EFC configuration is as follows:
builder.HasOne(ag_ch => ag_ch.Code)
.WithOne(c => c.AggregationChild)
.HasForeignKey<AggregationChildren>(ag_ch => ag_ch.AggregationChildrenId)
.OnDelete(DeleteBehavior.Restrict);
So we start with defining the relationship using HasOne
+ WithOne
.
Then HasForeignKey<AggregationChildren>(ag_ch => ag_ch.AggregationChildrenId)
to tell EF that (1) AggregationChildren
is the dependent end of the relationship, and (2) that the PK AggregationChildrenId
should also be used as FK.
Finally, OnDelete(DeleteBehavior.Restrict)
is the EFC equivalent of the EF6 WillCascadeOnDelete(false)
. The other options like ClientSetNull
and SetNull
apply only when the dependent has a separate optional FK, which is not the case with shared PK association.
Reference: Relationships
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With