Используя cookie для хранения сессии в ASP MVC
Ночные сборки не всегда необходимы - я думаю, что они только действительно полезны на больших проектах. Но если Вы находитесь на большом проекте, ночная сборка является хорошим способом проверить, что все работает - можно запустить все тесты (модульные тесты, интеграционные тесты), создать весь код - короче говоря, проверить, что ничто не повреждается в проекте.
, Если Вы имеете меньший проект Ваша сборка и тестируете времена, будет короче, таким образом, можно, вероятно, позволить себе сделать более регулярные сборки.
5 ответов
да, реализовать настраиваемый поставщик сеанса состояния . И нет, афаик нет более простого подхода.
Пс. это не так плохо, как кажется, т.е.> половина odbc sample записывается в базу данных.
зависит от того, какие данные вы хотите сохранить в файле cookie. Если вы хотите сохранить только строку, подойдет следующий код:
HttpCookie cookie = new HttpCookie("username","sth");
cookie.HttpOnly = true;
cookie.Expires = DateTime.Now.AddMonths(3);
HttpContext.Current.Response.Cookies.Add(cookie);
Я думаю, было бы намного эффективнее просто сохранить идентификатор сеанса (хеш или что-то еще) в cookie, а затем использовать этот идентификатор для получения данных сеанса из памяти / базы данных / чего угодно хранилище, которое вы предпочитаете. Сохранение полного состояния сеанса в файле cookie без необходимости увеличивает пропускную способность.
Также помните о безопасности: если файл cookie содержит информацию для аутентификации или другие конфиденциальные данные, и вы не будете осторожны, пользователь может легко взломать его, чтобы получить привилегии или иным образом нарушить работу вашего приложения (шифрование данных тоже отстой. , потому что тогда вам нужно кодировать зашифрованные данные в кодировке base-64, что дополнительно расходует пропускную способность и время обработки). Вы не должны никогда доверять вводу пользователя.
Я бы настоятельно не рекомендовал хранить весь сеанс в файлах cookie. Это плохо сказывается на производительности. Учтите это: каждый запрос (к каждому ресурсу) будет содержать накладные расходы, связанные с возможно устаревшими данными, которые вам понадобятся только один или два раза. В конечном итоге эти накладные расходы скажутся на ваших пользователях, пропускной способности и производительности вашего сайта.
Вот пример:
GET / HTTP/1.1
Host: localhost
OtherUsefulHeaders: foo
Cookie: YourSessionState=...
Начальный размер запроса составляет около 200 байт. Допустим, вы добавили к сеансу около 100 байт. Теперь размер 300 байт, а накладные расходы ~ 30%. Вы добавляете еще 100 байтов, и накладные расходы составляют 50%. Это означает, что примерно в 2 раза требуется время для отправки запроса и 2-кратная пропускная способность.
Вам лучше изучить реализацию TempData на основе файлов cookie , поскольку она занимает гораздо меньше места и действительно имеет смысл.
Вы не должны использовать сеансы для это, но вместо этого профили. Профили используют файлы cookie для сопоставления компьютеров с профилями и т. Д. Ключ профиля хранится в файле cookie и не теряется при закрытии браузера и т. Д.
Информация здесь; http://odetocode.com/articles/440.aspx