Entity Framework POCO отслеживание долгосрочных изменений - PullRequest
4 голосов
/ 15 мая 2011

Я использую .NET Entity Framework 4.1 с подходом «сначала код», чтобы эффективно решить следующую проблему, здесь упрощенно.

  • Есть таблица базы данных с десятками тысяч записей.
  • Несколько пользователей моей программы должны иметь возможность
    • просматривать (всю) таблицу в GridRow, что подразумевает необходимость загрузки всей таблицы.
    • Изменение значений любогослучайный ряд, изменения часты, но не должны сохраняться немедленно.Ожидается, что разные пользователи будут изменять разные строки, но это не всегда так.Допускается некоторая потеря изменений, поскольку пользователи, скорее всего, обновят одни и те же строки до тех же значений.
    • Иногда добавляют новые строки.

Звучит достаточно просто.Мой первоначальный подход состоял в том, чтобы использовать длительный экземпляр DbContext.Этот DbContext должен был отслеживать изменения в сущностях, поэтому при вызове SaveChanges() большая часть работы выполняется автоматически.Однако многие отмечают, что это не оптимальное решение в долгосрочной перспективе , особенно здесь .Я до сих пор не уверен, что понимаю причины, и не вижу, что такое единица работы в моем сценарии.Пользователь сам выбирает, когда следует сохранить изменения, и скажем, что клиент всегда выигрывает для простоты.Также важно отметить, что объекты, которые не были затронуты, не перезаписывают никакие данные в базе данных.

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

Как правильно решить эту проблему?

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

EDIT1 Еще один момент путаницы - этосуществование свойства Local на объекте DbSet<>.Он приглашает меня использовать длительный контекст, так как другой пользователь разместил здесь .

Ответы [ 2 ]

3 голосов
/ 15 мая 2011

Проблема с длительным контекстом заключается в том, что он не обновляет данные - я больше обсуждал проблемы здесь . Поэтому, если ваш пользователь откроет список и полчаса изменит данные, он не узнает об изменениях. Но в случае WPF, если ваше деловое действие:

  • Открыть список
  • Делай столько действий, сколько хочешь
  • Запуск сохранения изменений

Тогда все это единица работы, и вы можете использовать для этого один экземпляр контекста. Если у вас есть сценарий, в котором побеждает последнее изменение, у вас не должно быть проблем с этим, пока кто-то другой не удалит запись, которую редактирует текущий пользователь. Кроме того, после сохранения или отмены изменений вы должны удалить текущий контекст и снова загрузить данные - это гарантирует, что у вас действительно будут свежие данные для следующей единицы работы.

Контекст предлагает некоторые функции для обновления данных, но он обновляет только данные, ранее загруженные (без связей), поэтому, например, новые несохраненные записи будут по-прежнему включены.

Возможно, вы также можете прочитать о платформе MS Sync и локальном кэше данных.

1 голос
/ 15 мая 2011

Похоже, ваши пользователи могут хранить (кэшировать) данные в течение неопределенного периода времени.Чем дольше пользователи используют кэшированные данные, тем выше вероятность того, что они могут отключиться от соединения с базой данных в DbContext.Я предполагаю, что EF плохо с этим справляется, и вы, вероятно, захотите с этим справиться.(например, иногда подключенная архитектура).Я ожидаю, что реализация может решить многие ваши проблемы.

...