Следует хранить информацию о пользователе, который требуется для каждого запроса например. Роль, адрес электронной почты, имя пользователя и т. Д.Сохранять информацию о пользователе в сеансе?
в сеансе, или это нормально, чтобы получить базу данных каждый запрос на эту информацию?
Благодаря
Я предпочитаю использовать зашифрованные куки для этого. ДБ-вызовы могут стать дорогостоящими в больших, занятых системах. Сессия прекрасна, но если ваш бэкэнд сеанса подключен к базе данных, это тоже может стать дорогостоящим. Очевидно, что при использовании файлов cookie вы должны включить проверку токена проверки подлинности.
Это зависит от того, что вы подразумеваете под «Should». Я работал над несколькими приложениями, которые использовали сеанс для кэширования пользовательской информации. Этот подход хорошо зарекомендовал себя и уменьшил количество обращений к базам данных, необходимых для каждого веб-запроса.
С другой стороны, он вводит состояние вашим веб-серверам, поэтому вам нужно либо придерживаться одного веб-сервера, использовать «отвратительные сеансы» (что может затруднить управление веб-серверами), либо начать хранить информацию о сеансе в общем хранилище данных (который уничтожает любое увеличение производительности, которое, возможно, вам пришлось использовать, в первую очередь).
Данные сеанса также могут храниться в базе данных, что полезно, если ваш сайт работает в веб-садовом саду. Если в сеансе работает InProc, пользовательские данные будут сохранены в памяти, что намного быстрее, но за счет масштабируемости.
Другим распространенным способом было бы сохранить его как ViewState, после чего он отправляется обратно и четвертый между клиентом и сервером с каждой обратной передачей, что, конечно же, приводит к удару полосы пропускания, но значительно увеличивает эффективность сеанса InProc.
Лично мне нравится состояние сеанса лучше, если сайт небольшой, я запускаю его InProc, и если/когда сайт растет, я могу изменить его, чтобы вместо этого использовать базу данных.
Если вы не планируете балансировку нагрузки, то состояние сеанса вполне приемлемо. Будьте осторожны, если состояние сеанса сконфигурировано так, чтобы использовать постоянство базы данных, потому что тогда вы не только попадете в базу данных, но и нанесете накладные расходы на сериализацию объектов.
Если это данные, специфичные для пользователя, тогда может работать распределенная система кеш-таблиц. Такие вещи, как Memcached, хороши для этого, потому что они в кэше памяти (производительность), но распределены между несколькими серверами (балансировка нагрузки), поэтому вы получаете лучшее из обоих миров.
Конечно, если это данные, которые регулярно меняются, особенно если вы используете другие системы, которые могут изменять базу данных без знания веб-приложения, то возврат к базе данных может быть единственным вариантом.
Если вы используете хранилище сеансов memcache и знаете, какие данные пользователей вы изменяете, вы всегда можете аннулировать данные сеанса, если ключ сеанса каким-то образом связан с пользователем (f.ex map sessionId -> userId). Таким образом, вы можете использовать хранилище сеансов даже с частыми изменениями. – Runeborg
Да, но дело в том, что если происходят частые изменения, вам может быть лучше избегать накладных расходов (de) и просто перейти к базе данных. Это потребует измерения производительности, чтобы увидеть, какой метод лучше работает при загрузке. –
Я сохраняю идентификатор пользователя в сеансе, и я сохраняю активные записи пользователей в кеше для многих своих приложений, но опять же я стараюсь хранить содержимое всех моих раскрывающихся списков в кеше, и я должен представить раскрывающийся список пользователей время от времени.
У меня было много людей, восклицающих «OMG, вы храните это в кеше!?!?» но на самом деле, он отлично работает. Лучше, что у меня есть только одна копия списка пользователей в кеше, чем одна копия на экземпляр приложения (100 одновременных пользователей означают потенциально 100 копий списка пользователей в памяти). В общем, я помещаю все, что не часто меняется в кеше, и вытесняет его из кэша, если он изменится, поэтому он перезагрузится при следующем доступе.
Это зависит от вашего сайта/приложения.Общие правила таковы:
Сохранение в сеансе хорошо работает, если количество одновременных пользователей довольно низкое, а данные относительно малы.
Сохранение в файле cookie хорошо работает, если число одновременных пользователей велико, а размер данных относительно низок. Очевидно, что куки-файлы общедоступны, поэтому, если они чувствительны, такие как электронная почта, тогда они должны быть зашифрованы.
Сохранение в базе данных работает хорошо, если размер данных большой.
Примечание. Как говорили другие, если вы используете веб-ферму, я бы забыл о сохранении в сеансе.
Martin Fowler имеет хорошее описание вариантов в «Шаблонах архитектуры корпоративных приложений», но я не уверен, есть ли у него материал в Интернете.
Если сайт/приложение требует аутентификации, то .Net имеет хорошие встроенные функции для хранения пользовательских ролей и уникальных имен пользователей. Если вы сохраните это во время аутентификации, то эти значения можно получить через User.IsInRole() и User.Identity.Name.
Сохраняется в сеансе, что вызывает проблемы с производительностью? Если размер ваших данных относительно невелик, например, электронная почта, я бы пошел с использованием сеанса или файлов cookie и избегал базы данных. Запустите тесты производительности и посмотрите, что лучше всего подходит для вас.
аутентификация токен проверка? вы имеете в виду только формы auth? – Schotime
уверен, зависит от ваших потребностей! – grenade