Структура сущности: жизнь datacontext?

Question

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

В целом, вывод, который я вижу, заключается в том, что в настольных приложениях жизнь контекста данных должна быть жизнью формы, а в приложениях WCF жизнь должна быть жизнью сеанса.

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

Но, например, если я прочитал некоторые данные из базы данных и контекст данных, создайте как свойство формы в приложении для рабочего стола, если я вношу изменения, мне нужно только изменить значения в объектах контекст данных и вызовите метод savechanges() и EF, сохраните изменения в контексте данных. Таким образом, у меня есть два взаимодействия с базой данных: один для получения данных и других, чтобы сохранить изменения.

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

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

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

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

Итак, что является лучшим вариантом для работы с контекстом данных, в настольных приложениях и приложениях WCF? Возможно, я неправильно использую контекст данных?

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

Answer 1

Итак, что является лучшим вариантом для работы с контекстом данных, на рабочем столе приложений и приложений WCF?

Это зависит от конкретной ситуации, но в большинстве случаев это будет именно то, что вам нужно:

• WinForm/WPF - в виде/на ведущий и т.д.
• WCF - за вызов службы; никогда за сеанс или за приложение
• ASP.NET - за запрос; никогда на сессии или на приложение

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

Наиболее сложной ситуацией является многопоточная служба Windows, в которой вы должны вручную идентифицировать единицу работ и использовать соответствующий срок службы контекста. Никогда общий контекст между потоками. Избегайте, используя глобальные контексты продолжительности жизни, используемые для работы с несколькими подразделениями. Here - это связанное описание, почему совместное использование контекста является неправильной идеей.

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

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