Zwei Tabellen, die Schlüssel zueinander auf Entity Framework haben

Question

Ich habe die folgenden Klassen:

public class Condition 
{ 
    public int Id {get;set; } 
    public Condition ParentCondition {get;set;} 
    public Action ParentAction {get;set;} 
    public string Whatever {get;set;} 
} 

public class Action 
{ 
    public int Id {get;set; } 
    public Condition ParentCondition {get;set;} 
    public Action ParentAction {get;set;} 
    public string Whatever {get;set;} 
} 

So beide, den Zustand und die Aktion kann entweder eine Bedingung oder eine Aktion als Elternteil (oder keine, wenn beide sind null)

Ich habe versucht, dies auf eine SQL-Datenbank zu setzen, aber irgendwie verloren. Also etwas, was ich wollen würde wäre erreichen so etwas wie (Pseudo-Code)

TABLE Condition:

int ConditionParent 
int ActionParent 

Tabelle Action:

int ConditionParent 
int ActoinParent 

ich versucht, mit fließend api:

modelBuilder.Entity<Condition>() 
       .ToTable("Condition") 
       .HasOptional(c => c.ParentAction) 
       .WithRequired(a => a.ParentCondition); 

Aber wenn ich das mache, die Action Tabelle sieht gut aus, aber der Migrationscode für die Bedingung hat überhaupt keine Spalte für ein Aktionselement.

Was muss geändert werden?

Answer 1

Ich löste dies durch explizites Hinzufügen Ids:

public class Condition 
{ 
    public int Id {get;set; } 
    public int? ParentConditionId {get;set;} 
    public virtual Condition ParentCondition {get;set;} 
    public int? ParentActionId {get;set; } 
    public virtual Action ParentAction {get;set;} 
    public string Whatever {get;set;} 
} 

public class Action 
{ 
    public int Id {get;set; } 
    public int ParentConditionId {get;set;} 
    public virtual Condition ParentCondition {get;set;} 
    public int? ParentActionId {get;set;} 
    public virtual Action ParentAction {get;set;} 
    public string Whatever {get;set;} 
} 

Answer 2

Die Conditions Tabelle hat haben eine Spalte für ihre übergeordneten Aktion! Es ist der Primärschlüssel, der gleichzeitig ein Fremdschlüssel für Action ist.

Blick auf dem (wesentlich) Erstellungscode für die Tabellen:

CREATE TABLE [dbo].[Actions](
    [Id] [int] NOT NULL, 
    [ParentAction_Id] [int] NULL, 
CONSTRAINT [PK_dbo.Actions] PRIMARY KEY CLUSTERED ([Id])) 

ALTER TABLE [dbo].[Actions] ADD CONSTRAINT [FK_dbo.Actions_dbo.Actions_ParentAction_Id] 
    FOREIGN KEY([ParentAction_Id]) REFERENCES [dbo].[Actions] ([Id]) 

-- Here: primary key Id is foreign key to Condition 
ALTER TABLE [dbo].[Actions] ADD CONSTRAINT [FK_dbo.Actions_dbo.Conditions_Id] 
    FOREIGN KEY([Id]) REFERENCES [dbo].[Conditions] ([Id]) 

CREATE TABLE [dbo].[Conditions](
    [Id] [int] IDENTITY(1,1) NOT NULL, 
    [ParentCondition_Id] [int] NULL, 
CONSTRAINT [PK_dbo.Conditions] PRIMARY KEY CLUSTERED ([Id]) 
) 

ALTER TABLE [dbo].[Conditions] ADD CONSTRAINT [FK_dbo.Conditions_dbo.Conditions_ParentCondition_Id] 
    FOREIGN KEY([ParentCondition_Id]) REFERENCES [dbo].[Conditions] ([Id]) 

Dies liegt daran, Action - Condition ein 1: 1 Verband. EF implementiert immer erforderliche 1: 1-Verknüpfungen durch diese PK/FK-Konstruktion. Es macht Sinn: eine Action kann nicht ohne die erforderliche Condition Eltern existieren. Der beste Weg, dies zu garantieren ist, dass Action den PK-Wert "Condition" ausborgt.