Entity Framework Handbuch Datenbank Änderung

Question

Ich folge einem Kurs auf Udemy ein .net und MVC5-Projekt zu bauen. Dieses Projekt beinhaltet die Verwendung der Code-First-Design-Philosophie für Datenbanken. Ich habe ein paar Dinge durcheinandergebracht, während ich den Übungen folgte, also ging ich zum Tutor-Github-Code-Repository und lud einige der Klassen herunter. In einer der Klassen hatte er in einer Movie-Klasse einen Spaltennamen namens Genre_Id, während ich meine Version zu GenreId nenne. Also ging ich dumm in die Filmklasse und rief die Spalte Genre_Id an und ging zur Datenbank und benannte die Spalte manuell in Genre_Id um. Bei dieser manuellen Änderung wurden sofort Ausnahmen in meiner Anwendung ausgelöst.

Wenn ich versuche, meine App zu erstellen, bekomme ich Systemausnahmen geworfen. Ich habe etwas recherchiert, einen Beitrag gefunden, der vorgeschlagen hat, dass die Reinitialisierung von Migrationen die Ausnahmen lösen könnte. Daher habe ich meinen Migrationsordner gelöscht, die Datenbankverbindung getrennt und die Datenbank gelöscht, sodass ich die Migrationen und das Datenbankschema von Grund auf neu erstellen kann. Was ich nicht zu verstehen scheint ist, dass Visual Studio immer noch Migrationen mit Genre_Id1 erstellt, das ein Fremdschlüssel ist, wenn meine Klasse für einen Film diesen Spaltennamen nicht enthält.

Kann mir bitte jemand helfen, bevor ich die gesamte Lösung von Grund auf neu erstellen. Die Ausnahme, die ich habe, ist Inner Exception: Ungültiger Spaltenname 'Genre_Id1'. Ich habe in der gesamten Lösung nach Genre_Id1 gesucht, meine Klassen überprüft, sichergestellt, dass die Add-Migration InitialMigration, die Genre_Id1 enthielt, entfernt und durch Genre_Id ersetzt wurde, bevor ich die Datenbank aktualisierte, aber ich bin mir nicht sicher, wo oder Diesen Spaltennamen aufheben, da der Build-Prozess danach zu suchen scheint.

Alles andere kann ich ausprobieren, bevor ich das Projekt trash und neu starten.

Dank

Answer 1

Das Problem, das Sie stammt aus schlecht gewählter Standard Konvention von EF (nicht Sie) vor EF-Core erleben.

Wenn Sie eine Klasse mit Navigationseigenschaft haben und keine explcit FK Eigenschaft:

public class Movie 
{ 
    // ... 
    public Genre Genre { get; set; } 
} 

die implizierten Schatten FK Eigenschaft und den Spaltennamen ist Genre_Id.

Die Standardkonvention für den Namen der expliziten FK-Eigenschaft lautet jedoch GenreId (kein Unterstrich). Die, wenn sie geliefert ändert sich auch die implizite Spaltenname:

public class Movie 
{ 
    // ... 
    public int GenreId { get; set; } 
    public Genre Genre { get; set; } 
} 

Wenn Sie den Namen der Eigenschaft Genre_Id

public class Movie 
{ 
    // ... 
    public int Genre_Id { get; set; } 
    public Genre Genre { get; set; } 
} 

EF vereinbarungsgemäß als FK Eigenschaft nicht erkennen und wird versuchen, eine versteckte (Schatten) zu erstellen Eigenschaft mit dem Standardnamen Genre_Id. Da der Name von Ihrer Eigenschaft beibehalten wird, hängt EF ein Suffix an, um es eindeutig zu machen, daher wird Genre_Id1 in dem generierten SQL angezeigt.

Es gibt mehrere Möglichkeiten, wie Sie es beheben können.Ich persönlich bevorzuge fließend Konfiguration, weil es IMO sauberer, aber hier ist, wie Sie es mit Daten Anmerkungen auflösen kann:

Wenn Sie FK Eigenschaft wollen Genre_Id genannt, dann mit [ForeignKey] Attribut es als FK zur Karte:

public class Movie 
{ 
    // ... 
    [ForeignKey("Genre")] 
    public int Genre_Id { get; set; } 
    public Genre Genre { get; set; } 
} 

oder

public class Movie 
{ 
    // ... 
    public int Genre_Id { get; set; } 
    [ForeignKey("Genre_Id")] 
    public Genre Genre { get; set; } 
} 

Wenn Sie Eigenschaft GenreId genannt, verwenden Sie dann [Column] Attribut den Spaltennamen angeben:

public class Movie 
{ 
    // ... 
    [Column("Genre_Id")] 
    public int GenreId { get; set; } 
    public Genre Genre { get; set; } 
} 

Ich würde vorschlagen, dass Sie immer eine explizite Migration erstellen und sehen, was es enthält. Wenn Sie Spalten sehen, die nicht von Ihnen angegeben wurden, deutet dies auf eine falsche Konfiguration hin, die einen Konflikt mit den EF-Standardkonventionen verursacht.