Лучшая практика для сохранения и вызова выбранных флажков на странице asp.net - PullRequest
0 голосов
/ 17 июля 2009

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

Я буду перебирать список флажков и помещать выбранные значения в массив.

Где было бы хорошее место, чтобы сохранить этот набор данных? Я посмотрел на хранение объекта в базе данных или, возможно, XML-файл на сервере. Я также рассмотрел отправку данных в web.config, но хотел бы избежать перезапуска приложения.

Есть мнения или предложения?

ТИА

J

Ответы [ 5 ]

0 голосов
/ 17 июля 2009

Есть только два способа сделать то, о чем вы говорите.

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

  2. Сохраните его в таблице базы данных. Недостатком является то, что для получения данных требуется вызов базы данных.

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

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

Если бы моим бэкэндом был sql 2005 или 2008, я мог бы даже сделать еще один шаг и использовать объект SqlCacheDependency, чтобы кеш получался недействительным, как только произойдет обновление этой таблицы БД.

0 голосов
/ 17 июля 2009

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

Я бы создал таблицу, в которой достаточно столбцов, чтобы собрать всю информацию о каждом флажке. Например:

CREATE TABLE [CheckBoxStatus] (
[CheckBoxID] nvarchar(50),
[bool] bit NULL DEFAULT 0,
[SessionID] nvarchar(50));

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

То же самое происходит, если вы сохраняете, просто вставьте логические значения с соответствующими checkboxID и SessionID.

Это также должно работать, если ваши checkboxID'ы каким-то образом создаются динамически. Вам нужно только быть осторожным, чтобы независимо от того, что генерирует ваш checkboxID, чтобы быть уверенным, что он всегда генерирует один и тот же идентификатор для определенного вида флажка.

Таким образом, если это что-то вроде «Красной машины», то каждый раз, когда эта «Красная машина» отображается в одном и том же контексте, необходимо генерировать одинаковый идентификатор.

0 голосов
/ 17 июля 2009

Как насчет хранения их в куки? Создайте объект, который состоит из логических значений и сериализуйте в cookie:

class Checks() {
    public value1( get; set; )
    public value2( get; set; )
    public value3( get; set; )
    ...
    public valueN( get; set; )
}
0 голосов
/ 17 июля 2009

Я немного запутался в этом вопросе, вы упомянули WebSessions и даже подумали сохранить настройки в Webconfig, но сколько сеансов вы сохраните и как вы очистите неиспользуемые сессии, оставьте часть, которую рассматривает Web.config любой XML-файл, основные вопросы У меня

  • Являются ли настройки (выбор флажков) @ уровнем сеанса или уровнем приложения?
  • Каков период времени персистенции?
  • Требуются ли эти данные на сайте сервера для какой-либо другой обработки ИЛИ нормально, если они на стороне клиента.
  • Имеют ли пользователи уникальную идентификацию? Уникальные пользователи ??

Если требование ищет быстрого решения и не должно расти,

  1. В случае постоянства на стороне клиента используйте Cookies, а на стороне сервера есть пользовательский объект для представления состояния, считанного из Cookie
  2. В случае персистентности на стороне сервера используйте файл XML и схему, которая помогает идентифицировать уникальную идентификацию пользователя в качестве ключа, и загрузите настройки в пользовательском классе.

Если требование ищет долгосрочное решение и будет расти в будущем, используйте профили ASP.NET и, при необходимости, используйте доступных поставщиков профилей (SQL SERVER) или внедряете свой собственный поставщик профилей.

0 голосов
/ 17 июля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...