Является ли хорошей практикой избегать использования состояния сеанса в ASP.NET MVC? Если да, то почему и как?

Ответ 1

В ASP.NET Web Forms передача информации между разными страницами никогда не была особенно простой без использования сеанса. Из-за модели с обратной обратной связью информация была доступна на сервере как часть события, но часто на неправильной странице для отображения результата, обеспечивая необходимую информацию между страницами.

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

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

Из-за этих свойств сеанс больше не требуется выполнять базовые задачи в MVC и становится плохо подходящим, если раньше он казался совершенно правильным выбором.

По сути, сеанс загрязняет HTTP. Он делает запросы (часто содержащие их собственное состояние) зависящими от внутреннего состояния принимающего сервера. Вот почему это рассматривается как нечто злое (хотя часто и практическое и необходимое).

Ответ 2

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

Также, чтобы помочь вам избежать использования сеанса, ASP.NET имеет viewstate, которое на самом деле было огромным скрытым полем в ваших веб-формах, которые получили POSTed при каждой обратной передаче. Это также было слишком неуклюжим по разным причинам и было сброшено с помощью MVC.

Итак, сеанс - это то, что было не очень рекомендовано даже до MVC. Причина в основном - масштабируемость. Чем меньше вы сохраняете состояние, тем более масштабируемым будет ваш сайт. Если вы не заботитесь о масштабируемости (для чего я знаю, что вы можете разрабатывать приложение для интрасети для 200 пользователей), или если у вас очень мало информации, чтобы упорствовать, обязательно используйте сеанс. В других случаях использование сеанса полностью соответствует: типичный сценарий, в котором используется состояние сеанса, - это корзина покупок на сайте электронной торговли (информация, которая по сути является для каждого пользователя за сеанс и что только процент ваших пользователей фактически заполнен).

Что касается альтернатив, для сеанса нет прямой замены для замены. В зависимости от того, что вы пытаетесь сделать, вы можете использовать кеш или файлы cookie. MVC не принес ничего особо нового в этом отношении, AFAIK.

Ответ 3

Что бы это значит, чтобы избежать использования состояния сеанса для вас? Вам нужно удобно хранить небольшие объемы пользовательских данных по запросам? Если да, то как еще вы это сделаете?

Я не уверен, какими будут ваши альтернативы состоянию сеанса. Использование состояния сеанса, как оно есть, из коробки, в ASP.NET гораздо более желательно использовать собственную альтернативу, особенно с точки зрения безопасности.

Ответ 4

Используйте TempData вместо HttpSessionState. TempData - это оболочка Mvc состояния сеанса.

Ответ 5

Добавление к предыдущим ответам

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

Независимо от ASP.NET WebForms или ASP.NET MVC, как правило, с сеансом, мы представляем себе корзину покупок с загруженной или удаленной тележкой, которая поддерживается в течение всего сеанса. Таким образом, это был простой и дешевый способ делать вещи, обычно сеанс находится на

• InProc
• StateServer
• SQLServer
• Теперь в распределенном кеше подробнее

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

Таким образом, множественные узлы могут обслуживать запрос для одного пользователя в зависимости от loadbalancer, но мы можем отменить переопределение с помощью липкого сеанса в веб-уровне, который гарантирует, что текущий пользователь будет использовать одни и те же узлы, что не удается при масштабировании приложения, классический пример 1000 активных сеансов на каждый 2 node, и теперь мы добавляем еще один node, мы обычно ожидаем, что 3 узла будут иметь равное количество сеансов, однако это не так, как эти 1000 должны быть активны в определенных узлах, потому что мы используем липкий сеанс, масштабирование потребуется время, пока сеанс не будет очищен.

Опять же, что, если мы хотим расширить или изменить масштаб приложения? или один или несколько серверов будут потеряны, все данные сеанса будут потеряны, если мы продолжим сессию на InProc или StateServer и даже когда узлы веб-уровня переключаются для одного пользователя, тогда как если мы будем хранить на SQLServer, это нормально, но обычно медленно, так что ответ здесь похоже, является распределенным кешем, который является быстрым и может быть надежным.

Ответ 6

Это зависит от того, сколько данных вы сохраняете в состоянии сеанса. Как правило, я стараюсь просто использовать его для нескольких строк здесь и там и не намного больше. Например, для большой формы я могу сохранить ссылочный идентификатор для этого сеанса, а затем сохранить все необходимые данные в таблицах SQL temp на основе этого идентификатора. Это своего рода боль, но состояние сеанса не предназначено для хранения большого количества информации.

Ответ 7

Срок действия сеанса обычно не соответствует намерению пользователя (например, если IIS перерабатывает, ваше состояние сеанса inproc теряется). Единственное, что, по моему мнению, может быть полезно для кеширования пользовательских данных, а не для авторитетного источника правды (который, скорее всего, должен быть DB).

Ответ 8

Управление сеансами всегда вызывало трудности с ASP.NET Web Forms на ASP.net MVC. Однако MVC рекомендует использовать его как Stateless, поскольку вы пользуетесь веб-API REST. Большинство вещей, которые мы использовали для хранения в сеансе, ранее выполнялись с использованием комбинации MVC + Web API.