При получении идентификатора строки я обновил в SQL-сервере

Это позволяет Entity Framework создавать прокси-сервер вокруг виртуального свойства, чтобы свойство могло поддерживать ленивую загрузку и более эффективное отслеживание изменений. См. . Какие эффекты могут иметь ключевое слово virtual в Entity Framework 4.1. Код POCO First? для более подробного обсуждения.

Изменить, чтобы уточнить «создать прокси-сервер»: «создайте прокси-сервер». Я имею в виду конкретно то, что делает Entity Framework. Для платформы Entity Framework ваши свойства навигации должны быть помечены как виртуальные, чтобы поддерживать ленивую загрузку и эффективное отслеживание изменений. См. Требования к созданию прокси POCO . Entity Framework использует наследование для поддержки этой функции, поэтому она требует, чтобы определенные свойства были помечены как виртуальные в вашем базовом классе POCOs. Он буквально создает новые типы, которые происходят из ваших типов POCO. Таким образом, ваш POCO действует как базовый тип для динамически созданных подклассов Entity Framework. Это то, что я имел в виду под «созданием прокси-сервера».

Динамически созданные подклассы, созданные Entity Framework, становятся очевидными при использовании Entity Framework во время выполнения, а не во время статической компиляции. И только если вы включите ленивые функции загрузки или изменения отслеживания Entity Framework. Если вы решите никогда не использовать ленивые функции отслеживания загрузки или изменения в Entity Framework (который не является стандартным), вам не нужно объявлять какие-либо свойства навигации как виртуальные. Затем вы отвечаете за загрузку этих свойств навигации самостоятельно, используя то, что Entity Framework называет «нетерпеливой загрузкой», или вручную извлекает связанные типы для нескольких запросов к базе данных. Однако вы можете и должны использовать ленивые функции загрузки и изменения отслеживания для ваших свойств навигации во многих сценариях.

Если вы должны были создать отдельный класс и пометить свойства как виртуальные, а просто создать и использовать экземпляры этих классов в своем собственном приложении, полностью вне сферы действия Entity Framework, то ваши виртуальные свойства не будут Я ничего не выиграю.

Изменить, чтобы описать, почему свойства будут помечены как виртуальные

. Такие свойства, как:

 public ICollection RSVPs { get; set; }

Не являются полями и не должны рассматриваться как таковые. Они называются геттерами и сеттерами, а во время компиляции они преобразуются в методы.

//Internally the code looks more like this:
public ICollection get_RSVPs()
{
    return _RSVPs;
}

public void set_RSVPs(RSVP value)
{
    _RSVPs = value;
}

private RSVP _RSVPs;

Вот почему они помечены как виртуальные для использования в Entity Framework, что позволяет динамически созданным классам переопределять внутренние функции get и set. Если ваши свойства getter / setters для навигации работают для вас в вашем использовании Entity Framework, попробуйте пересмотреть их только на свойства, перекомпилировать и посмотреть, сможет ли Entity Framework функционировать должным образом:

 public virtual ICollection RSVPs;