Объясните пожалуйста, как работает Update в Entity Framework

Entity Framework реализует паттерн Единица работы (Unit of Work, UoW). Его назначение — представлять бизнес-транзакции на уровне предметной области (не на уровне доступа к данным).

Единица работы сохраняет набор изменений, например, добавление, изменение и удаление записей. Все изменения вносятся в базу при вызове метода SaveChanges. Копии записей БД хранятся в единице работы в одном из нескольких состоянии: не изменённые, изменённые, новые и удалённые.

Такой подход очень удобен в некоторых сценариях, но накладывает определённые ограничения. Мы не можем просто удалить записи в базе. Мы должны их загрузить и пометить, как удалённые. В некоторых случаях можно сконструировать запись в Единице работы и пометить её, как будто она загружена из базы, после чего "удалить".

Такое может потребоваться, если вы реализуете сложную логику, или пытаетесь оптимизировать доступ к данным. Моя рекомендация: для начала сделать простое работающее решение, а потом, если скорость действительно будет низкой, разбираться с записями на низком уровне.

Итак, простой способ что-то сделать с существующей записью — сначала её загрузить.

Удаление

    public IAsyncResult DeleteById(int id)
    {
        var record = dbContext.Funnels.SingleOrDefault(x => x.Id == id);
        if (record == null)
            return NotFound();
        dbContext.Funnels.Remove(record);
        dbContext.SaveChanges();
        . . .
    }

Обновление

    public IAsyncResult UpdateById(int id, FunnelModel model)
    {
        var record = dbContext.Funnels.SingleOrDefault(x => x.Id == id);
        if (record == null)
            return NotFound();
        record.Foo = model.Foo;
        record.Bar = model.Bar;
        record.Baz = model.Baz;
        dbContext.SaveChanges();
        . . .
    }

Обратите внимание, что при обновлении вам не надо явно помечать запись изменённой, то есть явно взывать Update. EF при загрузке из базы сохраняет её в состоянии "без изменений", а перед сохранением самостоятельно ищет все изменённые записи.

Если вам кажется, что это медленно — загружать записи чтобы их удалить или обновить, то вы правы. Unit of Work не про скорость работы, а про удобство при определённых сценариях.

При создании записи мы ничего не читаем, мы просто вызываем метод Add:

Создание

    public IAsyncResult Create(FunnelModel model)
    {
        dbContext.Records.Add(new Funnel
        {
            Foo = model.Foo,
            Bar = model.Bar,
            Baz = model.Baz,
        });
        dbContext.SaveChanges();
        . . .
    }

В этом сценарии возможны проблемы с коллизиями записей. Если у вас суррогатный ключ, значение которого генерируется в БД, обычно всё нормально. Но если значением ключа управляете вы сами, вы можете попытаться записать в базу что-то, что там уже хранится.

Такой сценарий часто возникает при попытке добавить или изменить запись, доступную через навигационное свойство.

        var record = dbContext.Funnels.SingleOrDefault(x => x.Id == id);
        if (record == null)
            return NotFound();
        record.AdvertiserFunnels.Add(new AdvertiserFunnel { . . . });

Здесь мы загружаем запись Funnel из базы, но не загружаем связанные с ней записи AdvertiserFunnels. Мы создаём новую связанную запись, и, возможно это приведёт к ошибке. Например, EF может удалить старые записи, поскольку их нет в его образе базы.

Большим плюсом Единицы работы и конкретно EF является то, что он позволяет работать с группой записей, как с единым целым. В DDD есть понятие агрегат — это такой сложный объект, состоящий из нескольких простых сущностей, которые отображаются на таблицы.

Чтобы избегать проблем, надо попросить EF загружать основную запись Funnel вместе с навигационными свойствами, которые мы планируем изменить. Делается это с помощью метода Include.

        var record = dbContext.Funnels
                              .Include(x => x.AdvertiserFunnels)
                              .SingleOrDefault(x => x.Id == id);
        if (record == null)
            return NotFound();
        record.AdvertiserFunnels.Add(new AdvertiserFunnel { . . . });

Теперь EF точно знает, какие дочерние записи лежат в базе и может безболезненно создать новую.

Насколько я понимаю, ошибка в вашей программе возникает как раз из-за того, что в dbContext не загружаются навигационные свойства.

UPDATE

Подробнее напишу про уровни. В классических трёхзвенных приложениях уровень предметной области зависел от уровня доступа к данным. В результате, чтобы загрузить сущности, вы прямо на уровне предметной области, например в коре какого-нибудь сервиса, лезли в базу:

class FooService
{
   public void MakeSomething()
   {
       using (var connection = new SqlConnection(_connectionString))
       using (var command = connection.CreateCommand();
       {
           . . .
           using (var dataReader = command.ExecuteReader())
           {
               var foo = Foo.CreatFromDataReader(dataReader);
               . . .
           }
       }
   }
}

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

Вторая проблема в том, что классы предметной области начинают слишком много знать про детали хранения. Эта информация им не нужна, но мы не можем без неё обходится. Класс Foo должен знать про System.Data.IDataReader и должен уметь себя оттуда читать.

Если нам потребуется транзакция, то мы сможем сделать её непосредственно для SQL-подключения.

Инвертировав зависимость, и введя интерфейс репозитория, мы уберём эти детали с уровня предметной области. Репозиторий — это большое хранилище наших сущностей, которое не помещается в память — такого знания достаточно на уровне предметной области.

Всё здорово, но методы репозитория могут обеспечивать атомарность и согласованность только на уровне отдельных агрегатов.

Агрегаты — это составные сущности. Скажем, заказ в магазине в базе хранится в двух таблицах: сам заказ и его позиции. Но на уровне кода Java/C#/Python у вас будет один агрегат, корневой сущностью которого будет заказ, и кроме заказа там будут ещё сущности-позиции заказа.

Репозиторий заказа может внести несколько правок в один заказ в рамках одной транзакции. А что делать, если у нас есть сценарий, где задействованы разные агрегаты?

Понятно, где это делать — если у нас несколько аграгатов, которыми мы оперируем, значит, у нас какой-то бизнес-сценарий. Для бизнес-сценариев мы заводим классы служб (классы сервисов). Но не создавать же там SqlTransaction вручную?

Чтобы спрятать транзакцию как раз и используют паттерн Unit of Work. Его интерфейс (как и интерфейсы репозиториев), описан на уровне предметной области. Реализация делается ниже — на уровне доступа к данным.

Что касается контроллеров, то они находятся над уровнем предметной области. Это уровень взаимодействия с пользователем или взаимодействия с внешней программой. Классическое название — уровень представления.