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

Question

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

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

Answer 1

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

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

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

• Получите это из базы данных еще раз.Минусы:Некоторые (небольшие) дополнительные накладные расходы на БД
• Сохраните его в сеансе пользователя.Минусы:Потенциально все еще попадающий в базу данных (если там сохранено состояние сеанса) или использующий много памяти (если там сохранено состояние сеанса) и может хранить несколько копий, если несколько пользователей могут обращаться к этому объекту, и, что хуже всего, этот объект сеанса может исчезнуть при отправке пользователем, если ASP.NET удалил его по какой-либо причине.
• Из Кэша.Минусы:Использует некоторую дополнительную память, и вам все равно придется обращаться к базе данных, если кэш не существует, но я бы поставил большие деньги на то, что у любого приложения есть много больших бутылочных горлышек для использования кэша.
• Состояние просмотра.Вы МОГЛИ бы сохранить объект в Viewstate (который отправляет его клиенту, затем клиент отправляет его обратно).Минусы:На мой взгляд, это худшее решение.Добавление его в Viewstate означает, что он передается по каналу вниз и вверх по течению и приводит к огромному размеру страницы.Сессия - это не самое лучшее, но Viewstate - это дьявол.

Answer 2

У вас много пользователей?

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

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

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

:)

Answer 3

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

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

<Ол>

Показать экран редактирования для клиента 1 на компьютере 1

Показать экран редактирования для клиента 1 на компьютере 2

Обработка обновления для клиента 1 с компьютера 1

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

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

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

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