Лучшие практики для создания клиента ADO.NET DataService

Question

У меня есть приложения Windows Forms и службы на стороне сервера, основанные на службе данных ADO.NET.Является ли плохой практикой создание и инициализация одного статического клиента службы данных в приложении Windows и использование его во всей программе?Например, я могу использовать его во всех открытых формах (которые имеют привязки к объектам datacontext службы), чтобы вызывать SaveChanges () и не терять отслеживание. Или лучше создать экземпляр клиента службы для каждой новой формы (потому что я думаю, что через некоторое время су одного статического клиента будет огромный рост памяти)?Но когда я создаю нового клиента для каждой формы, я предполагаю, что каждый раз создаю новое соединение со службой.

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

Answer 1

На самом деле класс DataServiceContext не создает соединение с сервисом. Используемый протокол OData основан на REST и, следовательно, не имеет состояния. Так что создание одного контекста даже не затрагивает сервис. Каждая операция (запрос, сохранение изменений) выдает отдельный и отдельный запрос к сервису. С точки зрения сервиса это просто количество не связанных запросов. Как отмечалось выше, обычно хорошей идеей является создание отдельного контекста для каждого «раздела» вашего приложения. Что именно это зависит от вашего приложения. Если вы не собираетесь загружать / отслеживать огромное количество объектов (не менее 1000), тогда один контекст может подойти. С другой стороны, несколько контекстов дают вам возможность «отменить» операции обновления, просто отбрасывая контекст и не вызывая SaveChanges, что может быть удобно в некоторых приложениях.

Answer 2

Я бы сказал: это зависит.;) Ну, ваша проблема знакома с решением, которое вы должны сделать, используя непосредственно Entity Framework.Поэтому я рекомендую вам поискать такие статьи и извлечь их точку зрения.

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

Если приложение простое, то правильный подход - использовать только один контекст.