为什么在实体框架模型定义中为类属性使用“虚拟”？

Question

在以下博客中：http : //weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

该博客包含以下代码示例：

public class Dinner

{

   public int DinnerID { get; set; }

   public string Title { get; set; }

   public DateTime EventDate { get; set; }

   public string Address { get; set; }

   public string HostedBy { get; set; }

   public virtual ICollection<RSVP> RSVPs { get; set; }

}

public class RSVP

{

   public int RsvpID { get; set; }

   public int DinnerID { get; set; }

   public string AttendeeEmail { get; set; }

   public virtual Dinner Dinner { get; set; }

}

virtual在类中定义属性时使用的目的是什么？它有什么作用？

Answer 1

virtualC＃中的关键字使子类可以覆盖方法或属性。有关更多信息，请参考“ virtual”关键字上的MSDN文档。更新：这不能像当前所提出的那样回答问题，但是我会将它留在这里，供任何寻求原始，非描述性问题的简单答案的人使用。

Answer 2

我了解OP的挫败感，对virtual的这种使用不是针对事实上的virtual修饰符有效的模板化抽象。如果有任何问题仍在努力中，我将提出自己的观点，因为我试图使解决方案保持简单，并将术语降到最低：简单的实体框架确实利用了延迟加载，这相当于为将来的执行做准备。这适合“虚拟”修饰符，但还有更多。在实体框架中，使用虚拟导航属性可以将其表示为SQL中可为空的外键的等效项。在执行查询时，您不必急于联接每个键控表，但是当您需要信息时，该表将成为需求驱动的。我还提到了nullable，因为许多导航属性起初并不相关。即在客户/订单方案中，您不必等到处理订单以创建客户的那一刻。可以，但是如果您有一个多阶段的流程来实现此目的，则可能会发现需要保留客户数据以供以后完成或部署到将来的订单中。如果实现了所有导航属性，则必须在保存文件上建立每个外键和关系字段。这实际上只是将数据设置回内存中，从而破坏了持久性的作用。因此，尽管在运行时实际执行中似乎有些神秘，但我发现要使用的最佳经验法则是：如果要输出数据（读入View模型或Serializable模型），并且在引用之前需要值，则不要使用虚拟 如果您的范围是在收集可能不完整或需要搜索的数据，并且不需要为搜索完成每个搜索参数，那么代码将很好地利用引用，类似于使用可空值属性int？长？。此外，从数据收集中抽象业务逻辑直到需要注入它，都具有许多性能优势，类似于实例化对象并将其从null开始。实体框架使用了大量的反射和动态特性，这会降低性能，并且需要具有可以根据需求扩展的灵活模型对于管理性能至关重要。对我来说，这总是比使用诸如代理，委托，处理程序之类的重载技术术语更有意义。一旦您碰到了第三个或第四个编程语言，它们就会变得凌乱。