Erläuterung der Eins-zu-Viele-Navigationseigenschaften in Entity Framework

Question

Ich bin ein wenig verwirrt durch widersprüchliche Beispiele von Eins-zu-Viele-Modellbeziehungen unter Verwendung von EF, die ich online sehe.

Ein Video sah ich Setup eine Beziehung zwischen Tabellen wie folgt:

public class CustomerType 
{ 
    public int Id { get; set; } 

    public string Name { get; set; } 
} 

public class Customer 
{ 
    public int Id { get; set; } 

    public string Name { get; set; } 

    public int CustomerTypeId { get; set; } 

    public CustomerType CustomerType { get; set; } 
} 

So ein Customer kann nur eine CustomerType haben, sondern ein CustomerType kann von vielen Customers verwendet werden. Dieser Code funktioniert gut, ich kann eine Customer 's CustomerType mit LINQ mit Include holen.

nun an einer anderen Ressource Ich suche die gleiche Art von Beziehung zeigt:

fast das gleiche Das sieht

public partial class Standard 
{ 

    public int StandardId { get; set; } 
    public string StandardName { get; set; } 

    public virtual ICollection<Teacher> Teachers { get; set; } 
} 

public partial class Teacher 
{ 
    public int TeacherId { get; set; } 
    public string TeacherName { get; set; } 

    public Nullable<int> StandardId { get; set; } 

    public virtual Standard Standard { get; set; } 
} 

, außer:

1. In diesem Beispiel ist die Standard Klasse (entspricht zu meiner CustomerType) hat eine Navigationseigenschaft zurück zu einer Sammlung von Teachers, die mein erstes Beispiel nicht hat. Ist das einfach praktisch, wenn ich eine Liste aller Lehrer für einen bestimmten Standard erhalten möchte oder ist es notwendig, die Beziehung richtig einzurichten?

2. Die Eigenschaften im zweiten Beispiel sind markiert virtual und die ersten sind nicht - es scheint, dass Best Practice ist, um Nav-Eigenschaften virtuell zu machen, aber gibt es einen Grund, warum Sie das nicht tun möchten?

Wenn es darauf ankommt, bin ich mit MVC5 und EF6 und ich möchte nur wissen, ob ein Beispiel richtig ist, und man ist falsch, oder nur zwei Arten von an der gleichen Stelle zu bekommen.

Danke!

Answer 1

Die Navigationseigenschaften sollen Abfragen für den Programmierer erleichtern. Ihre Beispiele sind im Wesentlichen die gleichen, mit dem Unterschied, dass Sie in Standard über Abfrage zugreifen können, während in CustomerType Sie Customers mit dieser CustomerType nicht zugreifen können, da Sie es nicht als Navigationseigenschaft haben. Sie können jedoch immer List<Customer> Customers in Customer Type einschließen.

Auch ist es besser, virtuell zu Ihrer Navigationseigenschaft wegen des faulen Ladens hinzuzufügen.

MSDN

Answer 2

Es hängt von Ihren Bedürfnissen, wenn Sie nie die Navigationseigenschaft bekommen und müssen nur einen Fremdschlüssel aus Gründen der Datenintegrität, dann können Sie einfach eine ganze Zahl addieren und als Fremdschlüssel markieren . ex: anstatt eine CustomerType Instanz zu haben, können Sie einfach eine CustomerTypeId haben und das ist es.

Was das virtual Schlüsselwort, können Sie es hinzufügen, wenn Sie einen verzögertes Laden in Ihrem DBContext aktiviert haben wollen, erzeugt Ursache EF-Proxy-Klassen, die von Ihrer Modellklasse erben und es überschreibt die virtuellen Eigenschaften die benötigte Logik hinzuzufügen Lazy laden Sie die Navigationseigenschaften.

Wenn Sie ein Lazy-Laden deaktiviert haben, müssen Sie keine Eigenschaft als virtual

markieren