Devo armazenar um campo ID de banco de dados no ViewState?

StackOverflow https://stackoverflow.com/questions/103000

  •  01-07-2019
  •  | 
  •  

Pergunta

Eu preciso recuperar um registro a partir de um banco de dados, exibi-lo em uma página da web (estou usando o ASP.NET), mas armazenar o ID (chave primária) de que em algum lugar registro para que eu possa voltar para o banco de dados mais tarde com que ID (talvez para fazer uma atualização).

Eu sei que há provavelmente algumas maneiras de fazer isso, como armazenar o ID no ViewState ou um campo escondido, mas o que é o melhor método e quais são as razões que eu poderia escolher esse método sobre quaisquer outros?

Foi útil?

Solução

Depende.

Você se importa se alguém vê o ID de registro? Se o fizer, então ambos os campos ocultos e viewstate não são adequados; você precisa armazená-lo em estado de sessão, ou viewstate criptografar.

Você se importa se alguém envia o formulário com um id falso? Se o fizer, então você não pode usar um campo oculto (e você precisa olhar para a proteção CSRF como um bônus)

Você quer isso imutável, mas não se preocupam com isso estar aberto para a visualização (com algum trabalho)? Use viewstate e definir enableViewStateMac = "true" na sua página (ou global)

Deseja-lo escondido e protegido, mas não pode usar o estado da sessão? Criptografar o estado de visualização, definindo a seguinte web.config entradas 

<pages enableViewState="true" enableViewStateMac="true" />
<machineKey ... validation="3DES" />

Outras dicas

Você quer que o usuário final para saber o ID? Por exemplo, se o valor do ID é um padrão 1,1 semente do banco de dados que eu poderia olhar para o número e ver quantos clientes você tem. Se você criptografar o valor (como a lata viewstate) eu iria encontrá-lo muito mais difícil de decifrar a chave (mas não impossível).

A alternativa é armazená-lo na sessão, isso vai colocar uma (muito pequeno se é apenas um inteiro) acerto de desempenho em sua aplicação, mas significa que eu como um usuário nunca vê que a chave primária. Ele também expõe o objeto para outras partes da sua aplicação, que você pode ou não quer que ele seja exposto a (objetos de sessão permanecerá até que seja limpa, um tempo definido (como 5 minutos) passa ou a janela do navegador for fechado - o que ocorrer mais cedo .

Veja valores de estado causar carga extra sobre o cliente após cada volta post, porque o viewstate não só economiza objetos para a página, mas se lembra de objetos se você usar o botão voltar. Isso significa que após cada volta post-it ViewState Obtém um pouco maior e mais difícil de usar. Eles só existirá em que página até que o navegador vai para outra página.

Sempre que eu armazenar um ID na página como esta, eu sempre criar uma propriedade 

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

ou 

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

Dessa forma, se você decidir alterá-lo de Viewstate para uma variável de sessão ou um campo de formulário oculto, é apenas um caso de mudá-lo na referência de propriedade, o resto da página pode acessar a variável usando "Page.CustomerID" .

ViewState é uma opção. É válido apenas para a página que você está. Ele não carrega através de solicitações para outros recursos como o objeto de sessão.

campos ocultos trabalhar muito, mas você está vazando e pouco de informação sobre a sua aplicação a qualquer pessoa suficientemente inteligente para ver a fonte de sua página.

Você também pode armazenar seu registro inteiro em ViewState e talvez evitar outra ida e volta ao th do servidor.

Eu, pessoalmente, estou muito desconfiado sobre colocar qualquer coisa na sessão. Muitas vezes os nossos processos de trabalho têm um ciclo e perdemos o nosso estado de sessão.

Como você descreve o seu problema, eu iria colocá-lo em um campo oculto ou no estado de visualização da página.

Além disso, ao determinar onde colocar os dados como este, sempre olhar para o escopo dos dados. É escopo para uma única página, ou para toda a sessão? Se a resposta for 'sessão' para nós, vamos colocá-la em um cookie. (Disclaimer:. Nós escrever aplicativos de intranet onde sabemos que os cookies estão habilitados)

Se seu um simples id vão optar por passá-lo na querystring, dessa forma você não precisa fazer postagens e página é mais acessível para os usuários e motores de busca. 

Session["MyId"]=myval;

Seria um pouco mais seguro e, essencialmente, oferece a mesma mecânica como colocá-lo no estado de visualização

Eu tendem a manter as coisas como que em campos escondidos apenas fazer um pouco 

 <asp:label runat=server id=lblThingID visible=false />
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top