Должен ли я хранить поле идентификатора базы данных во ViewState? - PullRequest
3 голосов
/ 19 сентября 2008

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

Я знаю, что, возможно, есть несколько способов сделать это, например, сохранить идентификатор в ViewState или в скрытом поле, но какой метод лучше, и по каким причинам я мог бы выбрать этот метод среди других?

Ответы [ 7 ]

6 голосов
/ 19 сентября 2008

Это зависит.

Вас волнует, увидит ли кто-нибудь идентификатор записи? Если вы это сделаете, то скрытые поля и viewstate не подходят; вам нужно сохранить его в состоянии сеанса или зашифровать состояние представления.

Вас волнует, если кто-то отправит форму с поддельным идентификатором? Если вы это сделаете, вы не сможете использовать скрытое поле (и вам нужно смотреть на защиту CSRF в качестве бонуса)

Хотите ли вы, чтобы это было неизменным, но вас не волнует, что оно открыто для просмотра (с какой-то работой)? Используйте viewstate и установите enableViewStateMac = "true" на своей странице (или глобально)

Хотите скрыть и защитить, но не можете использовать состояние сеанса? Зашифруйте ваш viewstate, установив следующие записи web.config

<pages enableViewState="true" enableViewStateMac="true" />
<machineKey ... validation="3DES" />
2 голосов
/ 19 сентября 2008

Хотите, чтобы конечный пользователь знал идентификатор? Например, если значение идентификатора - стандартное начальное число 1,1 из базы данных, я мог бы посмотреть на число и посмотреть, сколько у вас клиентов. Если вы зашифруете значение (как это может сделать представление), мне будет намного сложнее расшифровать ключ (но не невозможно).

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

Значения состояния просмотра вызывают дополнительную нагрузку на клиента после каждого возврата назад, поскольку состояние просмотра не только сохраняет объекты для страницы, но и запоминает объекты, если вы используете кнопку возврата. Это означает, что после каждого поста назад, viewstate становится немного больше и сложнее в использовании. Они будут существовать только на его странице, пока браузер не перейдет на другую страницу.

Всякий раз, когда я сохраняю идентификатор на странице, подобной этой, я всегда создаю свойство

public int CustomerID {
    get { return ViewState("CustomerID"); }
    set { ViewState("CustomerID") = value; }
}

или

    Public Property CustomerID() As Integer
        Get
            Return ViewState("CustomerID")
        End Get
        Set(ByVal value As Integer)
            ViewState("CustomerID") = value
        End Set
    End Property

Таким образом, если вы решите изменить его с Viewstate на переменную сеанса или скрытое поле формы, это всего лишь случай его изменения в ссылке на свойство, остальная часть страницы может получить доступ к переменной с помощью «Page.CustomerID» .

0 голосов
/ 19 сентября 2008

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

0 голосов
/ 19 сентября 2008

Я склонен воткнуть такие вещи в скрытые поля, просто сделаю немного

 <asp:label runat=server id=lblThingID visible=false />
0 голосов
/ 19 сентября 2008

Лично я очень осторожен с тем, чтобы что-то добавить в сессию. Слишком много раз наши рабочие процессы повторялись, и мы теряли наше состояние сеанса.

Поскольку вы описали свою проблему, я бы поместил ее в скрытое поле или в область просмотра страницы.

Кроме того, при определении того, куда поместить данные, подобные этим, всегда обращайте внимание на объем данных. Это ограничено одной страницей или всей сессией? Если для нас ответ «сессия», мы помещаем его в файл cookie. (Отказ от ответственности: мы пишем приложения для внутренней сети, где мы знаем, что куки включены.)

0 голосов
/ 19 сентября 2008

ViewState является опцией. Это действительно только для страницы, на которой вы находитесь. Он не переносит запросы к другим ресурсам, таким как объект Session.

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

Вы также можете сохранить всю свою запись в ViewState и, возможно, избежать повторного обращения к серверу.

0 голосов
/ 19 сентября 2008
Session["MyId"]=myval;

Это было бы немного безопаснее и, по сути, предлагало бы ту же механику, что и в режиме просмотра состояния

...