为什么导航属性在EF中默认为虚拟 [英] Why Navigation Properties are virtual by default in EF

问题描述

我在EF 6.x中使用了以下POCO类。

I have following POCO class being used in EF 6.x.

我的问题：为什么帖子的导航属性在博客实体下声明为虚拟？

My question: Why is the navigation property of 'Posts' under 'Blog' entity declared as virtual?

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; }  
}

推荐答案

如果您定义导航属性 virtual ，Entity Framework将在运行时创建一个从类派生的新类（动态代理），并使用它而不是您的原始类。这个新的动态创建的类包含第一次访问时加载导航属性的逻辑。这被称为惰性加载。它允许Entity Framework避免加载数据库中不需要的整个依赖对象树。

If you define your navigation property virtual, Entity Framework will at runtime create a new class (dynamic proxy) derived from your class and uses it instead of your original class. This new dynamically created class contains logic to load the navigation property when accessed for the first time. This is referred to as "lazy loading". It enables Entity Framework to avoid loading an entire tree of dependent objects which are not needed from the database.

在某些情况下，最好使用加载加载 ，特别是如果你知道你将在某个时候与相关对象进行交互。

In some circumstances, it is best to use "Eager Loading" instead, especially if you know that you will be interacting with related objects at some point.

Julie Lerman真的是所有实体框架的权威，她解释了这个过程在她的MSDN文章神秘的实体框架策略：加载相关数据

Julie Lerman really is the authority on all things Entity Framework, and she explains this process very well in her MSDN Article Demystifying Entity Framework Strategies: Loading Related Data

使用Include加载加载对于事先知道您想要查询所有核心数据的相关数据的方案很有用。但请记住两个潜在的缺点。如果您的包含或导航路径太多，则实体框架可能会生成性能不佳的查询。而您应该谨慎的返回更多的相关数据，这要归功于使用Include编程的简便性。

Eager loading with Include is useful for scenarios where you know in advance that you want the related data for all of the core data being queried. But remember the two potential downsides. If you have too many Includes or navigation paths, the Entity Framework may generate a poorly performing query. And you should be careful about returning more related data than necessary thanks to the ease of coding with Include.

懒惰加载非常方便地在幕后检索相关数据，以便您做出回应代码只是提到相关的数据。它也使编码更简单，但您应该认真对待数据库导致的交互程度。只需要一到两次就可以导致40次访问数据库。

Lazy loading very conveniently retrieves related data behind the scenes for you in response to code that simply makes mention of that related data. It, too, makes coding simpler, but you should be conscientious about how much interaction it’s causing with the database. You may cause 40 trips to the database when only one or two were necessary.

如果您正在开发一个Web应用程序，服务器是一个新的上下文，Lazy Loading将只是创建不必要的开销来维护永远不会加载的相关对象的动态类。许多人会在这些情况下禁用延迟加载。最终，最好还是评估一下EF已经构建的SQL查询，并确定哪些选项对于您正在开发的方案来说最有效。

If you are developing a Web Application where every communication with the server is a new context anyway, Lazy Loading will just create unnecessary overhead to maintain the dynamic class for related objects that will never be loaded. Many people will disable lazy loading in these scenarios. Ultimately, it's still best to evaluate your SQL queries which EF has built and determine which options will perform best for the scenario you are developing under.

这篇关于为什么导航属性在EF中默认为虚拟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！