web-dev-qa-db-fra.com

Pourquoi les propriétés de navigation sont virtuelles par défaut dans EF

J'ai la classe POCO suivante utilisée dans EF 6.x.

Ma question: Pourquoi la propriété de navigation de 'Posts' sous l'entité 'Blog' est-elle déclarée virtuelle?

public class Blog 
{  
    public int BlogId { get; set; }  
    public string Name { get; set; }  
    public string Url { get; set; }  
    public string Tags { get; set; }  

    public virtual ICollection<Post> Posts { get; set; }  
}
entity-frameworknavigation-properties
38
Sunil

Si vous définissez votre propriété de navigation virtual, Entity Framework crée au moment de l'exécution une nouvelle classe (proxy dynamique) dérivée de votre classe et l'utilise à la place de votre classe d'origine. Cette nouvelle classe créée dynamiquement contient une logique pour charger la propriété de navigation lors de son premier accès. C'est ce qu'on appelle le "chargement paresseux". Il permet à Entity Framework d'éviter de charger une arborescence entière d'objets dépendants qui ne sont pas nécessaires à partir de la base de données.

Dans certaines circonstances, il est préférable d'utiliser à la place "Chargement avide", surtout si vous savez que vous allez interagir avec des objets associés à un moment donné.

Julie Lerman est vraiment l'autorité sur tout ce qui concerne Entity Framework, et elle explique très bien ce processus dans son article MSDN Démystifier les stratégies Entity Framework: Chargement des données connexes

Un chargement passionné avec Include est utile pour les scénarios où vous savez à l'avance que vous souhaitez que les données associées pour toutes les données de base soient interrogées. Mais rappelez-vous les deux inconvénients potentiels. Si vous avez trop d'inclusions ou de chemins de navigation, Entity Framework peut générer une requête peu performante. Et vous devez faire attention à ne pas renvoyer plus de données connexes que nécessaire grâce à la facilité de codage avec Include.

Le chargement paresseux récupère très commodément les données liées en arrière-plan pour vous en réponse au code qui fait simplement mention de ces données liées. Cela simplifie également le codage, mais vous devez être consciencieux quant à l'interaction qu'il provoque avec la base de données. Vous pouvez provoquer 40 déplacements dans la base de données alors qu'un ou deux étaient nécessaires.

Si vous développez une application Web où chaque communication avec le serveur est de toute façon un nouveau contexte, Lazy Loading créera simplement une surcharge inutile pour maintenir la classe dynamique des objets associés qui ne seront jamais chargés. De nombreuses personnes désactiveront le chargement paresseux dans ces scénarios. En fin de compte, il est toujours préférable d'évaluer vos requêtes SQL qu'EF a construites et de déterminer les options qui fonctionneront le mieux pour le scénario dans lequel vous développez.

78
Claies