Должен ли я использовать сеансы?

Question

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

Я использую проверку подлинности Windows Forms, и как только пользователь входит в систему, я создаю объект расписания (мой собственный пользовательский класс).

Как часть этого класса, у меня есть конструктор, который проверяет информацию в БД SQL (последние записи этого пользователя, пользовательские настройки и т. Д.)

Должен ли я хранить эту информацию всессия?А потом сначала проверять объект сеанса в конструкторе?Это кажется очевидным подходом, но большинство примеров, на которые я смотрел, редко используют сессии.Есть ли что-то, чего я не знаю, что делают другие (особенно связанные с сессиями .NET, конечно)?

РЕДАКТИРОВАТЬ: Я забыл упомянуть две вещи.
1.Моя база данных SQL находится на другом сервере (хотя я полагаю, что они оба находятся в одной сети, поэтому проблем не возникает)
2.Существуют определенные константы, которые пользователь не сможет изменить (их может изменять только администратор), например задачи проекта.Они используются на каждой странице, но загружаются в первый раз из БД.Должен ли я хранить их в сеансе?Если нет, то где еще?
Единственный другой способ, который я могу придумать, - это локальный плоский файл, который обновляется каждый раз при обновлении таблицы проектов, но это похоже на взломанное решение.Я слишком стараюсь минимизировать обращения к БД?

Answer 1

Хороший обзор сеанса ASP.NET можно найти здесь: Состояние сеанса ASP.NET .

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

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

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

Answer 2

Разработчики ASP знают состояние сеанса как отличную функцию, но она несколько ограничена. Эти ограничения включают в себя:

Состояние сеанса ASP существует в процессе, в котором размещается ASP; таким образом действия, которые влияют на процесс, также влияют на состояние сеанса. Когда процесс перезапускается или происходит сбой, состояние сеанса теряется. Ограничения фермы серверов. Когда пользователи переходят с одного сервера на другой в ферме веб-серверов, их состояние сеанса не отслеживается. Состояние сеанса ASP зависит от компьютера. Каждый сервер ASP предоставляет свое собственное состояние сеанса, и если пользователь не вернется на тот же сервер, состояние сеанса будет недоступно.
http://msdn.microsoft.com/en-us/library/ms972429.aspx

Answer 3

Я бы уклонялся от сессионных объектов. И на самом деле я бы сказал, посмотрите также .net MVC.

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

Я бы сохранил всю информацию, которую вы поместили бы в сеанс, в БД. Это позволит лучше отслеживать метрики, поддерживать Azure (не по теме, но стоит упомянуть) и будет более чистым imo.

Answer 4

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

Если вы МОЖЕТЕ хотеть несколько веб-серверов или приложение МОЖЕТ расти, не используйте сессию. И используйте его только для небольших фрагментов информации.

Answer 5

Недостаток состояния сеанса

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

ПРИМЕЧАНИЕ: - Я не упомянул о преимуществах, поскольку они просты: простота реализации, специфичные для сеанса события, сохранение данных, поддержка Cookie и т. Д..

Answer 6

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

Я бы сказал, что для этого конкретного случая сохраняйте ваши значения в базе данных и читайте их оттуда в любое время, когда вам понадобится эта информация. Как только у вас это получится, посмотрите на производительность сайта. Если он работает нормально, то оставьте его в покое (так как это самый простой случай для программирования). Если производительность является проблемой, обратите внимание на использование IIS Cache (вместо сеанса) или внедрение системы, подобной CQRS.

Answer 7

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

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

Конечно, вы можете переместить свою сессию на SqlServer или StateServer, но тогда вы потеряете в производительности.

Answer 8

Просмотрите свойство HttpContext.User (IPrincipal).это где информация пользователя хранится в запросе.