在以下博客中：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在類中定義屬性時使用的目的是什么？它有什么作用？
3 回答
慕尼黑5688855
TA貢獻1848條經驗 獲得超2個贊
virtualC＃中的關鍵字使子類可以覆蓋方法或屬性。有關更多信息，請參考“ virtual”關鍵字上的MSDN文檔。
更新：這不能像當前所提出的那樣回答問題，但是我會將它留在這里，供任何尋求原始，非描述性問題的簡單答案的人使用。
拉丁的傳說
TA貢獻1789條經驗 獲得超8個贊
我了解OP的挫敗感，對virtual的這種使用不是針對事實上的virtual修飾符有效的模板化抽象。
如果有任何問題仍在努力中，我將提出自己的觀點，因為我試圖使解決方案保持簡單，并將術語降到最低：
簡單的實體框架確實利用了延遲加載，這相當于為將來的執行做準備。這適合“虛擬”修飾符，但還有更多。
在實體框架中，使用虛擬導航屬性可以將其表示為SQL中可為空的外鍵的等效項。在執行查詢時，您不必急于聯接每個鍵控表，但是當您需要信息時，該表將成為需求驅動的。
我還提到了nullable，因為許多導航屬性起初并不相關。即在客戶/訂單方案中，您不必等到處理訂單以創建客戶的那一刻。可以，但是如果您有一個多階段的流程來實現此目的，則可能會發現需要保留客戶數據以供以后完成或部署到將來的訂單中。如果實現了所有導航屬性，則必須在保存文件上建立每個外鍵和關系字段。這實際上只是將數據設置回內存中，從而破壞了持久性的作用。
因此，盡管在運行時實際執行中似乎有些神秘，但我發現要使用的最佳經驗法則是：如果要輸出數據（讀入View模型或Serializable模型），并且在引用之前需要值，則不要使用虛擬 如果您的范圍是在收集可能不完整或需要搜索的數據，并且不需要為搜索完成每個搜索參數，那么代碼將很好地利用引用，類似于使用可空值屬性int？長？。此外，從數據收集中抽象業務邏輯直到需要注入它，都具有許多性能優勢，類似于實例化對象并將其從null開始。實體框架使用了大量的反射和動態特性，這會降低性能，并且需要具有可以根據需求擴展的靈活模型對于管理性能至關重要。
對我來說，這總是比使用諸如代理，委托，處理程序之類的重載技術術語更有意義。一旦您碰到了第三個或第四個編程語言，它們就會變得凌亂。
- 3 回答
- 0 關注
- 450 瀏覽
添加回答
舉報
0/150
提交
取消