Сессии в ASP.NET Core
ASP.NET Core разрабатывается таким образом, чтобы ваше приложение зависело только от функций, которые ему действительно нужны. Это достигается в значительной степени за счет создания составного фреймворка, в котором разработчик выбирает несущественные функции, многие из которых встроены в традиционные версии ASP.NET . Одной из функций, к которой это относится, является состояние сеанса. В этой статье рассматривается, как получить и использовать состояние сеанса в ASP.NET Core приложения.
Если вы новичок в ASP.NET , состояние сеанса - это механизм, который позволяет вам временно сохранять и извлекать определенные пользователем значения. Эти значения могут храниться в течение всего сеанса посетителя на вашем сайте. В большинстве случаев они хранятся в памяти сервера, хотя существуют варианты использования механизмов постоянного и/или распределенного хранения, если, например, вы используете несколько веб-серверов для своего приложения (веб-ферма и т.д.). В этой статье вас интересует только опция in-memory. Тип данных, для которых вы будете использовать состояние сеанса, - это все, что относится к текущему пользователю. Это может быть их имя, или уровень скидки, на который они имеют право, или что-то еще, для чего вы не хотите повторно запрашивать базу данных.
Управление сеансами в ASP.NET Core поставляется с помощью подключаемого компонента или "промежуточного программного обеспечения" и доступно в пакете Nuget под названием Microsoft.AspNet.Core.Session. Когда вы используете управление сеансами, вам также необходим механизм сохранения переменных сеанса. Хранилище в памяти также доступно в качестве дополнительного пакета под названием Microsoft.Extensions.Caching.Memory. Чтобы сделать их доступными для вашего приложения, добавьте следующие записи в узел зависимостей вашего файла project.json:
"Microsoft.AspNetCore.Session": "1.0.0l"
"Microsoft.Extensions.Caching.Memory": "1.0.0"
You should see "Restoring..." appear next to the References node in Solution Explorer and the session package being added.
Теперь, когда пакеты доступны для вашего приложения, вы можете отказаться от их использования. Вы делаете это в методе ConfigureServices класса Startup (файл Startup.cs).
public void ConfigureServices(IServiceCollection services)
{
// Add framework services.
services.AddMvc();
services.AddCaching();
services.AddSession(options =>
{
options.IdleTimeout = TimeSpan.FromMinutes(30);
options.CookieName = ".MyApplication";
});
}
Выделенные строки показывают код, который вам нужно добавить в метод ConfigureServices, чтобы зарегистрировать как кэширование, так и сеанс со службами, используемыми в вашем приложении. Метод использует делегат Action<SessionOptions>, который позволяет вам изменять параметры по умолчанию, такие как местоположение файлов cookie сеанса или период ожидания по умолчанию (который составляет 20 минут, как и в предыдущих версиях). Приведенный выше пример кода устанавливает значение тайм-аута равным 30 минутам. Это означает, что если пользователь простаивает более 30 минут, сеанс истекает, и его содержимое удаляется из памяти (если это резервное хранилище, которое вы решили использовать). Он также изменяет имя файла cookie, используемого для управления сеансами, которое по умолчанию равно .AspNet.Session.
На этом этапе вы включили необходимые пакеты для управления сеансами в свое решение, а затем зарегистрировали их как службы. Теперь вам нужно указать приложению использовать функции управления сеансами. Вы делаете это в методе Configure файла StartUp.cs, в котором вы регистрируете все промежуточное программное обеспечение, но убедитесь, что вы добавили сеанс в конвейер перед добавлением MVC. :
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
app.UseSession();
//removed for brevity
}
Вы можете начать настройку и получение значений сеанса после того, как обратитесь к Microsoft.AspNetCore.Http
в вашем контроллере:
using Microsoft.AspNetCore.Http;
Существует три метода, которые позволяют вам устанавливать значения сеанса: SetInt32, Set String и Set, который принимает массив байтов в качестве аргумента. Это сильно отличается от традиционного API сеанса, который позволяет вам устанавливать значение сеанса, присваивая ключу сеанса любой тип. Новая структура сеанса хранит элементы в виде байтовых массивов, а внутренне SetInt и setString преобразуют передаваемые вами целые числа и строки в байтовый массив. Основная причина этого решения, по-видимому, заключается в обеспечении сериализации значений сеанса для хранения на удаленных серверах. Единственный способ сохранить другие типы значений - это самостоятельно реализовать сериализацию в байтовые массивы. Я рассмотрю это вкратце, а пока вот как вы могли бы использовать методы SetInt32 и setString из вашего контроллера для создания и установки некоторых переменных сеанса:
public IActionResult Index()
{
HttpContext.Session.SetString("Name", "Mike");
HttpContext.Session.SetInt32("Age", 21);
return View();
}
И вот как вы можете получить эти значения для передачи в представление:
public IActionResult About()
{
ViewBag.Name = HttpContext.Session.GetString("Name");
ViewBag.Age = HttpContext.Session.GetInt32("Age");
return View();
}
Существует также метод Get, который возвращает массив байтов. Как я упоминал ранее, если вы хотите установить другие типы в качестве переменных сеанса, вам нужно самостоятельно позаботиться о сериализации. Вы могли бы сделать это на этапе установки значений, но более многоразовый подход может быть достигнут путем создания собственных методов расширения в ISession. В следующем примере показано, как можно реализовать методы getBoolean и SetBoolean:
public static class SessionExtensions
{
public static bool? GetBoolean(this ISession session, string key)
{
var data = session.Get(key);
if (data == null)
{
return null;
}
return BitConverter.ToBoolean(data, 0);
}
public static void SetBoolean(this ISession session, string key, bool value)
{
session.Set(key, BitConverter.GetBytes(value));
}
}
Теперь вы тоже можете использовать эти методы:
public IActionResult Index()
{
Context.Session.SetString("Name", "Mike");
Context.Session.SetInt32("Age", 21);
Context.Session.SetBoolean("Fibber", true);
return View();
}
public IActionResult About()
{
ViewBag.Name = Context.Session.GetString("Name");
ViewBag.Age = Context.Session.GetInt32("Age");
ViewBag.Liar = Context.Session.GetBoolean("Fibber");
return View();
}
Есть два других метода, представляющих интерес. Одним из них является метод удаления, который позволяет вам удалять отдельные значения из коллекции сеансов по ключу:
Context.Session.Remove("Name");
Другой - это Clear метод. При этом удаляются все ключи и значения, связанные с сеансом. Не существует очевидного аналога pre-ASP.NET Core метод отказа, который завершает сеанс.
События сессии
Классический ASP.NET включает в себя несколько событий, связанных с сеансом: Session_Start и Session_End, к которым вы можете получить доступ через global.asax для выполнения кода. В ASP.NET Core 1.0 вы можете запросить коллекцию сеансов с помощью промежуточного программного обеспечения, чтобы установить, был ли уже установлен сеанс для репликации события Session_Start, но нет планов вводить эквивалент Session_End. Поскольку одна из движущих сил, стоящих за ASP.NET Core - это "готовность к облаку", основное внимание при проектировании управления сеансами было уделено тому, чтобы заставить его работать в распределенном сценарии. Session_And срабатывает только тогда, когда сеансы используются в режиме proc (локальная память сервера), и команда заявила, что они не будут добавлять функции, которые работают только локально.
Webucator, специализированный поставщик онлайн- ASP.NET мы подготовили видеоверсию этой статьи:
Резюме
Цель этой статьи - представить тот факт, что состояние сеанса является компонентом выбора в ASP.NET Core 1.0 и имеет некоторые различия в именах и использовании методов по сравнению с традиционными ASP.NET . В приведенном здесь примере в качестве резервного хранилища значений сеанса использовалась память, хотя ограничения этого подхода остаются теми же, что и в предыдущих версиях ASP.NET . Память энергозависима, и на нее нельзя положиться. Он может быть удален в результате ряда причин, не зависящих от разработчика. В будущих статьях я рассмотрю альтернативные хранилища сохраняемости.
Только полноправные пользователи могут оставлять комментарии. Аутентифицируйтесь пожалуйста, используя сервисы.