Хранить информацию о пользователях в сеансе?

Question

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

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

Спасибо

Answer 1

Если вы не планируете балансировку нагрузки, то состояние сеанса вполне приемлемо. Будьте осторожны, если состояние сеанса настроено на использование постоянства базы данных, потому что тогда вы не только попадете в базу данных, но и понесете издержки сериализации объектов.

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

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

Answer 2

Это зависит от вашего сайта / приложения. Общие правила примерно такие:

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

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

Сохранение в базе данных хорошо работает, если размер данных большой.

Примечание. Как уже говорили другие, если вы используете веб-ферму, тогда я забуду о сохранении в сеансе.

Мартин Фаулер имеет хорошее описание параметров в «Шаблонах архитектуры корпоративных приложений», но я не уверен, есть ли у него что-то в сети.

Если сайт / приложение требует аутентификации, тогда .Net имеет хорошую встроенную функциональность для хранения пользовательских ролей и уникальных имен пользователей. Если вы сохраните это во время аутентификации, то к этим значениям можно будет получить доступ через User.IsInRole () и User.Identity.Name.

Хранение в сеансе вызывает проблемы с производительностью? Если размер ваших данных относительно невелик, таких как электронная почта, я бы использовал сеанс или куки и избегал базы данных. Запустите тесты производительности и посмотрите, что лучше для вас.

Answer 3

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

У меня было много людей, которые восклицали: "О боже, ты держишь это в кэше!?!?" но на самом деле это прекрасно работает. Лучше иметь ровно одну копию списка пользователей в кэше, чем одну копию на экземпляр приложения (100 одновременных пользователей означают потенциально 100 копий списка пользователей в памяти). В общем случае я помещаю в Cache все, что не часто меняется, и вытесняю его из Cache, если он меняется, поэтому он будет перезагружаться при следующем доступе.

Answer 4

Данные сеанса также могут храниться в базе данных, что полезно, если ваш сайт работает в Web Garden og Farm. Если в сеансе выполняется InProc, пользовательские данные будут сохранены в памяти, что намного быстрее, но за счет масштабируемости.

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

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

Answer 5

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

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

Answer 6

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