Борьба с допустимым использованием переменной Session в ASP.NET - PullRequest
Новая
       6

Борьба с допустимым использованием переменной Session в ASP.NET

3 голосов
/ 07 мая 2009

Я пытался отучить себя от прерывания всего в переменной Session в ASP.NET (я пришел из среды программирования Windows), и я вообще полностью прекратил явное хранение чего-либо в переменной Session. Кто-нибудь может дать некоторые рекомендации относительно того, что, по вашему мнению, является приемлемым использованием переменной сеанса?

Вот конкретный пример ... Я загружаю бизнес-объект из базы данных, заполняю и редактирую экран. Пользователь может редактировать значения и сохранять. По старинке я загружал бизнес-объект, загружал форму и сохранял бизнес-объект в переменной сеанса. Если пользователь нажмет кнопку «Сохранить», я получу бизнес-объект из переменной сеанса, заменим отредактированные значения и сохраню его. Новый способ загрузки бизнес-объекта из базы данных и загрузки формы. Пользователь будет редактировать значения и нажимать кнопку «Сохранить». Я бы перезагрузил свой бизнес-объект из базы данных, заменил отредактированные значения и затем сохранил его. Я не специалист по веб-программированию, но я чувствую, что первый путь неверен из-за плохого клейма использования переменных сеанса, и я чувствую, что второй путь неверен, потому что это просто дурацкий способ сделать это (загрузить бизнес-объект дважды ). Давайте не будем принимать во внимание какую-либо форму кэширования здесь. Как бы я справился с этим?

Ответы [ 3 ]

7 голосов
/ 07 мая 2009

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

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

Ваши варианты возврата этого бизнес-объекта в память при отправке назад:

  • Получите это снова из БД. Минусы: некоторые (небольшие) дополнительные издержки БД
  • Сохраните его в сеансе пользователя. Минусы: Потенциально все еще попадание в базу данных (если там хранится состояние сеанса) или использование большого количества памяти (если там хранится состояние сеанса) и может хранить несколько копий, если несколько пользователей могут обращаться к этому объекту и, что хуже всего, этот сеанс объект может быть пропущен, если пользователь нажимает «Отправить», если ASP.NET по какой-либо причине его очистил.
  • из кеша. Минусы: использует некоторую дополнительную память, и вам все равно придется обращаться к БД, если кеша не существует, но я бы потратил большие деньги на то, чтобы у любого приложения было гораздо больше узких мест для использования кеша.
  • ViewState. Вы МОЖЕТЕ сохранить объект в Viewstate (который отправляет его клиенту, затем клиент отправляет его обратно). Минусы: худшее решение, на мой взгляд. Добавление его в Viewstate означает, что оно идет по проводам вниз по течению и вверх по течению и приводит к огромному размеру страницы. Сессия не самая лучшая, но Viewstate - это дьявол.
1 голос
/ 07 мая 2009

Много ли у вас пользователей?

Сохранение ваших бизнес-объектов в сеансе может быть в порядке, если ваш сайт имеет малый объем.

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

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

:)

0 голосов
/ 07 мая 2009

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

Например, если происходит этот поток:

  1. Отображение экрана редактирования для клиента 1 на компьютере 1
  2. Отображение экрана редактирования для клиента 1 на компьютере 2
  3. Обработка обновления для клиента 1 с компьютера 1
  4. Обработка обновления для клиента 1 с компьютера 2

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

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

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

...