Почему должен, или разве я не должен хранить Набор данных, Таблицу данных, и т.д. как переменная сеанса на странице ASP.NET?
Я работаю над веб-приложением, которое использует Набор данных, возвращенный веб-сервисом.
Когда приложение работает, я храню тот Набор данных как переменную сеанса, которая будет использоваться много раз, поскольку пользователь перешел к различным страницам, которые отредактируют таблицы в наборе данных.
Идея была пользователем, должен будет только ожидать данных однажды, когда загрузки приложения затем приложение использовало бы переменную сеанса, пока пользователь не сохраняет изменения, которые они внесли, когда это происходит, это передало бы отредактированные таблицы службе для обновления базы данных.
Есть ли проблемы с этим дизайном и устройством хранения данных Набора данных и Таблиц данных как переменная сеанса? За и против сообщены мне.
4 ответа
Единственное преимущество:
- Это быстрее, чем многократное обращение к вашей базе данных. Тем не менее, корпоративные базы данных выполняют достаточно кэширования, которое вам не требуется.
Минусов много, но три основных:
- Если данные изменены из другого сеанса (скажем, пользователя с правами администратора), сеанс вашего пользователя не знает.
- Выделение памяти может очень быстро стать серьезной проблемой. (хотя это можно облегчить, используя кэш вместо сеанса и вводя ключ для идентификатора сеанса)
- Если вы когда-нибудь перейдете на серверную ферму, вам придется переосмыслить весь свой дизайн, вполне возможно, используя БД для хранения сеанса Данные - тогда ваш аргумент эффективности будет выглядеть немного слабым
[Edit] Как отмечали другие, существует также проблема с сохранением чего-либо в сеансе или кэше (или, в меньшей степени, в приложении), не сохраняя это в более постоянном месте. Если сеанс истекает или даже сбрасывается (я видел конфигурации оборудования, которые заставляют сеанс начинаться и заканчиваться с каждым запросом. Хотя он сохраняет идентификатор сеанса, все данные, хранящиеся в объектах сеанса, теряются.Если приложение перезапускается по какой-либо причине, все объекты сеанса, кэша и приложения очищаются. Объекты кэша могут очищаться в любое время просто потому, что среда решает, что это пространство памяти нужно для чего-то еще.
Вкратце: это не путь.
Если вам нужно, чтобы пользователь мог внести изменения, а затем нажать «Сохранить», чтобы сохранить их, сохраните отдельный набор таблиц состояний, в которых подробно описаны изменения, которые должны быть внесены в основные таблицы, когда пользователь нажимает «Сохранить». Хранить cookie на клиенте с ключом, срок действия которого истекает в далеком будущем; используйте этот файл cookie, чтобы сопоставить данные о вашем состоянии с пользователем.
Хранение слишком многого в сессии имеет следующие риски:
- Много пользователей с большой сессией потребуют больше ресурсов сервера.
- Если сессия пользователя закончится (например, прерывание телефонного разговора), все его данные будут потеряны, и ему придется начинать процесс заново. Хранение его данных в процессе перемещения по веб-страницам может привести к более приятным впечатлениям, если он решит продолжить работу позже.
Если вам нужно хранить что-то в сессии, чтобы сделать то, что вы описали, возможно, стоит рассмотреть возможность использования специального типа для этой цели вместо общего Dataset или DataTable.
Являются ли данные специфичными для пользователя? Если нет, то в конечном итоге вы будете хранить "№ пользователей, вошедших в систему" в таблице данных. Возможно, вы можете использовать какой-то механизм кэширования, если вас беспокоит задержка.
Большой недостаток: наборы данных огромны, поэтому хранение их всех в памяти сервера является проблемой, особенно когда количество пользователей начинает расти.