Entity Framework CTP 5 - шаблон репозитория - выполнение обновлений - PullRequest
8 голосов
/ 28 января 2011

Как бы вы выполнили операцию обновления с CTP 5, используя DbContext и шаблон Repository?Ранее с EF 4.0 это можно было сделать, как показано ниже.

_context.Customers.AddObject(item);
_context.ObjectStateManager.ChangeObjectState(item, System.Data.EntityState.Modified);

Есть ли причина, по которой EF не предоставляет простой способ обновления «отключенных» объектов.Я не хочу запрашивать БД и копировать все свойства объекта, который возвращается из запроса.Другими словами, EF должен иметь метод update, который принимает сущность (аналогично методу Add).Если ключ сущности уже существует в базе данных, обновите сущность текущими значениями.то есть, почему мы должны сделать «Присоединить», а затем скопировать все свойства в прикрепленный объект.Мне кажется излишним копировать все свойства сущностей просто для обновления, когда «отключенный» объект уже существует.

1 Ответ

8 голосов
/ 28 января 2011

Я полагаю, что вы все равно можете выполнить тот же метод, что и в своем примере кода, чтобы обновить отключенную сущность с помощью CTP5 DbContext:

_dbContext.Customers.Add(item);
DbEntityEntry entry = _dbContext.Entry(item);
entry.State = EntityState.Modified;

_dbContext.SaveChanges();

Глядя на сгенерированный SQL, это, конечно, создает полный оператор обновления для всех свойств объекта customer, включая свойства, которые на самом деле не изменились, поскольку EF не знает, каково текущее состояние в базе данных. Если вы хотите этого избежать, я полагаю, что нет другого способа, кроме выборки текущего состояния в базе данных перед обновлением, которое можно выполнить следующим образом:

DbEntityEntry entry = _dbContext.Entry(_dbContext.Customers.Find(item.ID));
entry.CurrentValues.SetValues(entity);

_dbContext.SaveChanges();

(Предполагается, что здесь у вас есть ключ ID для объекта клиента "item".)

Это создает оператор обновления SQL, который включает только те свойства, которые действительно изменились по сравнению с состоянием в базе данных. Я не уверен, что второй способ обязательно является менее производительным вариантом из-за дополнительного оператора select. Если тип объекта большой, но только очень немногие свойства изменились, накладные расходы на отправку полного оператора обновления для всех полей могут быть больше, чем оператор выбора, плюс «маленький» оператор обновления только с полями, которые действительно необходимы для обновления. (Но это только предположение, я не специалист по SQL Server.)

...