Сессия ASP.NET

Question

Сессия ASP.NET

Первым аргументом для полей внешнего ключа должна быть сама модель, а не строка модели (например, не «Team», а Team - аналогично для EmailTemplate)

 class TestSuite(models.Model):
     # Change this field's first argument from a string to the Team class
     team_name = models.ForeignKey(Team, on_delete=models.DO_NOTHING, db_column='team_name')
     suite_name = models.CharField(max_length=100)
     description = models.CharField(max_length=200, blank=True, null=True)
     schedule = models.CharField(max_length=100, blank=True, null=True)
     email_list_ok = models.CharField(max_length=200, blank=True, null=True)
     email_list_fail = models.CharField(max_length=200, blank=True, null=True)
     # Change this field's first argument from a string to the EmailTemplates class
     template_name = models.ForeignKey(EmailTemplates, on_delete=models.DO_NOTHING, db_column='template_name')

     class Meta:
         managed = False
         db_table = 'test_suite'
         unique_together = (('team_name', 'suite_name'),)

24

asp.net session session-state

задан Seb Nilsson 25 September 2008 в 13:44

13 ответов

Два варианта временного хранения данных формы - это, во-первых, сохранение информации о каждой форме в переменных переменной состояния сеанса и, во-вторых, передача информации о форме с использованием параметров URL-адреса. Использование файлов cookie в качестве потенциального третьего варианта просто не работает по той простой причине, что у многих ваших посетителей, вероятно, отключены файлы cookie (однако это не влияет на файлы cookie сеанса). Кроме того, я предполагаю по характеру вашего вопроса, что вы не хотите хранить эту информацию в таблице базы данных, пока она не будет полностью зафиксирована.

Использование переменных Session является классическим решением этой проблемы, но оно имеет ряд недостатков. Среди них (1) большие объемы данных могут занимать ОЗУ сервера, если вы используете управление сеансами inproc, (2) совместное использование переменных сеанса между несколькими серверами в ферме серверов требует дополнительных соображений, и (3) профессионально разработанное приложение должно Защита от истечения сеанса (не просто приведите переменную сеанса, а используйте ее - если сеанс истек, приведение вызовет ошибку). Однако для подавляющего большинства приложений переменные сеанса, несомненно, являются подходящим способом.

Альтернативой является передача информации о каждой форме в URL. Основная проблема с этим подходом состоит в том, что вам нужно быть чрезвычайно осторожным в «передаче» информации. Например, если вы собираете информацию на четырех страницах, вам необходимо собрать информацию на первой странице, передать ее в URL-адресе на вторую страницу, где вы должны сохранить ее в состоянии просмотра этой страницы. Затем при вызове третьей страницы вы будете собирать данные формы со второй страницы, а также переменные состояния представления и кодировать их как в URL-адресе и т. Д. Если у вас есть пять или более страниц или если посетитель будет переходить по сайту, вы в ваших руках будет настоящий беспорядок. Имейте также в виду, что вся информация должна быть A) сериализована в строку, безопасную для URL, и B) закодирована таким образом, чтобы предотвратить простые взломы на основе URL (например, если вы указали цену открытым текстом и передали ее вместе кто-то может изменить цену). Обратите внимание, что вы можете уменьшить некоторые из этих проблем, создав своего рода «диспетчер сеансов» и заставив его управлять строками URL для вас, но вам все равно придется быть чрезвычайно чувствительным к возможности того, что любая данная ссылка может уничтожить весь сеанс, если это не удалось должным образом.

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

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

К счастью, предусмотрительное использование переменных Session может избежать проблем с памятью (большие элементы должны храниться в базе данных в любом случае), и если вы используете сайт, достаточно большой, чтобы требовать фермы серверов, существует множество механизмов, доступных для создания состояния общего доступа. в ASP.NET (подсказка: вы не будете использовать inproc storage).

Чтобы избежать практически всех остальных недостатков Session, я рекомендую реализовать объект для хранения данных сеанса, а также некоторые простые возможности управления объектами Session. Затем встроите их в потомок класса Page и используйте этот класс Page для всех своих страниц. Тогда вам будет просто получить доступ к вашим данным Session через класс страницы в виде набора строго типизированных значений. Обратите внимание, что поля вашего объекта дадут вам доступ к каждой из ваших «переменных сеанса» строго типизированным способом (например, одно поле на переменную).

Дайте мне знать, если это простая задача для вас или вам нужен пример кода!

19