Подтвердить что ты не робот

Рамификации DbSet.Create против нового объекта()

Я немного смущен о том, использовать ли DbSet.Create или просто создать новую сущность и добавить ее. Я действительно не понимаю последствия использования DbSet.Create.

Я понимаю, что DbSet.Create создаст проксированную версию, если это применимо, но я действительно не понимаю, что это значит. Почему меня это волнует? Мне кажется, что пустой класс Proxied не более полезен, чем непроксированный класс, так как нет связанных объектов для ленивой загрузки.

Можете ли вы сказать мне разницу, за пределами очевидной? И почему вас это волнует?

4b9b3361

ОТВЕТЫ

Ответ 1

Сценарий, в котором использование DbSet<T>.Create() имеет смысл, заключается в прикреплении существующего объекта к контексту и последующем использовании ленивой загрузки связанных объектов. Пример:

public class Parent
{
    public int Id { get; set; }
    public virtual ICollection<Child> Children { get; set; }
}

public class Child
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Далее будет работать следующее:

using (var context = new MyDbContext())
{
    var parent = context.Parents.Create();
    parent.Id = 1; // assuming it exists in the DB
    context.Parents.Attach(parent);

    foreach (var child in parent.Children)
    {
        var name = child.Name;
        // ...
    }
}

Здесь запускается ленивая загрузка детей (возможно, в результате пустой коллекции, но не null). Если вы замените context.Parents.Create() на new Parent(), цикл foreach будет сбой, потому что parent.Children всегда null.

Edit

Другой пример был здесь (заполнение свойства внешнего ключа для нового объекта, а затем получение свойства навигации, лениво загружаемого после того, как новый объект вставлен в БД): Lazy load properties after вставка