Je comprends la frustration des OP, cette utilisation du virtuel n'est pas pour l'abstraction basée sur des modèles pour laquelle le modificateur virtuel de facto est efficace.
Si certains luttent toujours avec cela, je voudrais offrir mon point de vue, car j'essaie de garder les solutions simples et le jargon au minimum:
Entity Framework dans une pièce simple utilise le chargement paresseux, ce qui équivaut à préparer quelque chose pour une exécution future. Cela correspond au modificateur «virtuel», mais il y a plus à cela.
Dans Entity Framework, l'utilisation d'une propriété de navigation virtuelle vous permet de la désigner comme l'équivalent d'une clé étrangère nullable en SQL. Vous n'avez PAS à joindre avec impatience chaque table à clés lorsque vous effectuez une requête, mais lorsque vous avez besoin des informations, elles dépendent de la demande.
J'ai également mentionné nullable car de nombreuses propriétés de navigation ne sont pas pertinentes au premier abord. Par exemple, dans un scénario client / commandes, vous n'avez pas à attendre le moment où une commande est traitée pour créer un client. Vous pouvez, mais si vous aviez un processus en plusieurs étapes pour y parvenir, vous pourriez trouver la nécessité de conserver les données client pour une exécution ultérieure ou pour le déploiement sur des commandes futures. Si toutes les propriétés de navigation ont été implémentées, vous devez établir chaque clé étrangère et champ relationnel lors de la sauvegarde. Cela remet vraiment les données en mémoire, ce qui détruit le rôle de la persistance.
Donc, même si cela peut sembler cryptique dans l'exécution réelle au moment de l'exécution, j'ai trouvé que la meilleure règle empirique à utiliser serait: si vous générez des données (lecture dans un modèle de vue ou un modèle sérialisable) et que vous avez besoin de valeurs avant les références, ne le faites pas utiliser virtuel; Si votre portée recueille des données qui peuvent être incomplètes ou un besoin de recherche et ne nécessitent pas tous les paramètres de recherche complétés pour une recherche, le code fera bon usage de la référence, similaire à l'utilisation des propriétés de valeur nullable int? longue?. En outre, l'abstraction de votre logique métier de votre collecte de données jusqu'à la nécessité de l'injecter présente de nombreux avantages en termes de performances, similaires à l'instanciation d'un objet et son démarrage à null. Entity Framework utilise beaucoup de réflexion et de dynamique, ce qui peut dégrader les performances, et la nécessité d'avoir un modèle flexible pouvant s'adapter à la demande est essentielle à la gestion des performances.
Pour moi, cela avait toujours plus de sens que d'utiliser un jargon technologique surchargé comme les mandataires, les délégués, les gestionnaires et autres. Une fois que vous avez atteint votre troisième ou quatrième langue de programmation, cela peut devenir compliqué.