EF 4.1 DBContext и свойства навигации

Мы использовали EF STE некоторое время, но наше приложение значительно выросло, и мы решили подать в суд на новый 4.1 DbContext, чтобы мы могли «развить» отдельный бизнес-уровень поверх нашего уровня данных без необходимости использовать разные типы. для этого.

При элементарной оценке способа работы DbContext я столкнулся с небольшой проблемой.

Я привык запрашивать и предварительно загружать необходимые связанные данные, такие как:

return context.Orders.Include("Detail").SingleOrDefault(ord => ord.ID == ID);

А затем отправить возвращенный объект в пользовательский интерфейс для модификации, а при возврате из пользовательского интерфейса сохранить изменения в базе данных.

Из того, что я читал до сих пор, выполнение «сохранения изменений» в DbContext легко выполняется с помощью такого кода:

context.Entry(order).State = EntityState.Modified;

Проблема с этим кодом заключается в том, что он фактически помечает все свойства объекта как измененные, что не разрешено для некоторых свойств в моей модели (бизнес-правило).

Я прибег к следующему решению (которое, кажется, требует большого количества кода для относительно небольшого требования! Кстати, изменение измененного состояния свойства на Unchanged не поддерживается):

context.Orders.Attach(order);

DbEntityEntry<Order> ordEntity = context.Entry(order);

string[] arr =
{
      ordEntity.Property(ord => ord.ID).Name,
      ordEntity.Property(ord => ord.ClientID).Name,
};

foreach (string prop in ordEntity.OriginalValues.PropertyNames)
{
      if (!arr.Contains(prop))
      {
            ordEntity.Property(prop).IsModified = true;
      }
}

context.SaveChanges();

Проблема, с которой я сталкиваюсь в этом коде, заключается в том, что оператор «Прикрепить» генерирует исключение, говорящее о каком-то конфликте в свойствах навигации в прикрепленном объекте, даже если вообще ничего не было изменено! (сохранение объекта точно в том виде, в котором он был извлечен из базы данных). Сообщение об ошибке выглядит примерно так: «Обнаружены конфликтующие изменения роли «Подробности» отношения «OrdersDatamodel.FK_Order_Detail».

Вопросы:

  1. Есть ли более «элегантный» способ предотвращения изменения определенных свойств объекта?
  2. Кто-нибудь знает, что происходит с исключением, возникающим при присоединении объекта к контексту?

Спасибо.


c# entity-framework dbcontext ado.net-entity-data-model entity-framework-4.1
person wassim    schedule 18.02.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Из того, что я читал до сих пор, выполнение «сохранения изменений» в DbContext легко выполняется с помощью такого кода:

context.Entry(order).State = EntityState.Modified;

Вам редко нужно явно устанавливать состояние. Когда вы изменяете свойства, предполагая, что они virtual, состояние автоматически изменится на Modified без необходимости его установки. В противном случае DetectChanges уловит это во время вашего звонка SaveChanges.

person Community    schedule 18.02.2012
comment
Я больше не использую этот код. Как я уже упоминал в своем вопросе, мне пришлось вручную прикрепить объект к контексту (что оставляет объект в неизмененном состоянии), а затем отметить свойства, которым разрешено изменять вручную. Спасибо, в любом случае. - person wassim; 18.02.2012
comment
Но я пытаюсь подчеркнуть, что вы пытаетесь решить не проблему. Вам не нужно вручную отмечать сущность/свойства как измененные, потому что EF сделает это за вас. - person ; 18.02.2012
comment
Моя проблема с нестандартным поведением, о котором вы говорите, заключается в том, что оно позволяет изменять любое свойство. Я не могу разрешить модификацию определенных свойств, поэтому мне нужно убедиться, что только указанный набор свойств помечен как измененный (происходит ли пометка автоматически или вручную, на самом деле не проблема. Я решил пометить их как измененные вручную, потому что мои усилия по не удалось отменить отметку свойств, доступных только для чтения!). - person wassim; 19.02.2012
comment
Ах, спасибо за разъяснение. Можно ли в первую очередь предотвратить изменение этих свойств (за счет того, что установщик свойств выдает исключение, в зависимости от состояния объекта), вместо того, чтобы впоследствии пытаться отменить изменения? Или предназначены внутренние непостоянные модификации? - person ; 19.02.2012