實體框架屬性中的虛擬關鍵字

Question

public class Student
{
    public int StudentId;
    public string StudentName;
    public int CourseId;
    public virtual Course Courses { get; set; }
}

public class Course
{
    public int CourseId;
    public string CourseName;
    public string Description;
    public ICollection<Student> Students {get;set;}
    public ICollection<Lecture> Lectures { get; set; }
}

public class Lecture
{
    public int LectureId;
    public string LectureName;
    public int CourseId;
    public virtual Course Courses { get; set; }
}

這里使用的關鍵字virtual是什么？

有人告訴我虛擬是為了延遲加載，但我不明白為什么。 因為當我們做

_context.Lecture.FirstOrDefault()

結果返回第一個Lecture並且它不包括屬性Course 。

要獲得帶有Course的Lecture ，我們必須使用：

_context.Lecture.Include("Courses").FirstOrDefault()

不使用virtual關鍵字，它已經是一個延遲加載。

那為什么我們需要關鍵字呢？

Answer 1

通過將其聲明為virtual ，您允許 EF 將 value 屬性替換為代理以啟用延遲加載。 使用Include()是告訴 EF 查詢預先加載相關數據。

在 EF6 及之前的版本中，默認啟用延遲加載。 對於 EF Core，默認情況下它是禁用的。 （或在最早的版本中不支持）

進行以下查詢：

var lecture = _context.Lecture.Single(x => x.LectureId == lectureId);

加載一堂課。

如果您省略virtual然后訪問lecture.Course將做兩件事之一。 如果 DbContext (_context) 尚未跟蹤lecture.CourseId 指向的課程實例，則lecture.Course 將返回#null。 如果 DbContext 已經在跟蹤該實例，則 Lecture.Course 將返回該實例。 因此，如果沒有延遲加載，您可能會或可能不會獲得參考，不要指望它在那里。

在同一場景中使用virtual加載和延遲加載，代理會檢查 Course 是否已由 DbContext 提供，如果是則返回。 如果它還沒有被加載，那么它會自動 go 到 DbContext 如果它仍然在 scope 並嘗試查詢它。 這樣，如果您訪問lecture.Course ，如果數據庫中有記錄，您可以指望它被返回。

將延遲加載視為安全網。 如果依賴它會帶來潛在的顯着性能成本，但有人可能會爭辯說，與具有不一致數據的運行時錯誤相比，性能損失是兩害相權取其輕。 這在相關實體的 collections 中非常明顯。 在您上面的示例中， ICollection<Student>等也應標記為virtual ，以確保它們可以延遲加載。 否則，您將取回當時可能跟蹤的任何學生，這可能是運行時非常不一致的數據 state。

例如，您有 2 門課程，課程 #1 和 #2。 有 4 名學生，A、B、C 和 D。所有 4 人都注冊到課程 #1，只有 A 和 B 注冊到課程 B。如果我們通過刪除virtual來忽略延遲加載，那么行為將根據如果我們碰巧在一種情況下急切加載而在第二種情況下忘記了，我們首先加載哪個課程......

using (var context = new MyAppDbContext())
{
    var course1 = context.Courses
        .Include(x => x.Students)
        .Single(x => x.CourseId == 1);
    var course2 = context.Courses
        .Single(x => x.CourseId == 2);

    var studentCount = course2.Students.Count();
}

免責聲明：在實體中使用 collections 時，您應該確保它們始終被初始化，以便它們准備好 go。 這可以在構造函數或自動屬性中完成：

public ICollection<Student> Students { get; set; } = new List<Student>();

在上面的示例中，studentCount 將返回為“2”，因為在加載課程 #1 時，學生 A 和 B 都是通過Include(x => x.Students)加載的但這種情況在加載共享數據的多條記錄時很容易發生，例如搜索結果等。它還受到 DbContext 存活時間的影響。 此示例對新的 DbContext 實例 scope using塊，該實例的范圍為 web 請求，或者可以跟蹤調用早期的相關實例。

現在反轉場景：

using (var context = new MyAppDbContext())
{
    var course2 = context.Courses
        .Include(x => x.Students)
        .Single(x => x.CourseId == 2);
    var course1 = context.Courses
        .Single(x => x.CourseId == 1);

    var studentCount = course1.Students.Count();
}

在這種情況下，只有學生 A 和 B 被急切加載。 雖然課程 1 實際上引用了 4 個學生，但這里的 studentCount 將為與課程 1 關聯的兩個學生返回“2”，當課程 1 加載時 DbContext 正在跟蹤這些學生。 知道您沒有預先加載學生，您可能會期望 4 或 0。 生成的相關數據是不可靠的，您可能會或可能不會返回的內容將取決於情景。

延遲加載會變得昂貴的地方是加載數據集。 假設我們加載了一個包含 100 名學生的列表，並且在與這些學生一起工作時，我們訪問了 student.Course。 急切加載將生成 1 個 SQL 語句以加載 100 名學生及其相關課程。 延遲加載最終會為學生執行 1 個查詢，然后為每個學生執行 100 個查詢來加載課程。 （即 SELECT * FROM Courses WHERE StudentId = 1; SELECT * FROM Courses WHERE StudentId = 2; ...）如果學生有幾個延遲加載的屬性，那么每個延遲加載還有 100 個查詢。