Devo archiviare un campo ID database in ViewState?

Question

Devo recuperare un record da un database, visualizzarlo su una pagina Web (sto usando ASP.NET) ma memorizzare l'ID (chiave primaria) da quel record da qualche parte in modo da poter tornare al database in seguito con quell'ID (forse per fare un aggiornamento).

So che probabilmente ci sono alcuni modi per farlo, come la memorizzazione dell'ID in ViewState o in un campo nascosto, ma qual è il metodo migliore e quali sono i motivi per cui potrei scegliere questo metodo rispetto ad altri?

Answer 1

Dipende.

Ti interessa se qualcuno vede l'ID record? Se lo fai, entrambi i campi nascosti e viewstate non sono adatti; è necessario memorizzarlo nello stato della sessione o crittografare viewstate.

Ti interessa se qualcuno invia il modulo con un ID falso? Se lo fai, non puoi utilizzare un campo nascosto (e devi guardare la protezione CSRF come bonus)

Lo vuoi immutabile ma non ti interessa che sia aperto alla visualizzazione (con qualche lavoro)? Utilizza viewstate e imposta enableViewStateMac = " true " sulla tua pagina (o globalmente)

Vuoi nasconderlo e proteggerlo ma non puoi utilizzare lo stato della sessione? Cripta il tuo viewstate impostando le seguenti voci web.config

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

Answer 2

Desideri che l'utente finale conosca l'ID? Ad esempio, se il valore ID è un seme 1,1 standard dal database, potrei guardare il numero e vedere quanti clienti hai. Se si crittografa il valore (come il viewstate può) troverei molto più difficile decifrare la chiave (ma non impossibile).

L'alternativa è archiviarlo nella sessione, questo metterà un colpo di prestazione (molto piccolo se è solo un numero intero) sulla tua applicazione ma significa che io come utente non vedo mai quella chiave primaria. Espone inoltre l'oggetto ad altre parti dell'applicazione, a cui potresti o non vorrebbe che fosse esposto (gli oggetti della sessione rimangono fino a quando non vengono cancellati, passa un tempo prestabilito (come 5 minuti) o la finestra del browser viene chiusa - qualunque cosa accada prima .

I valori dello stato di visualizzazione causano un carico aggiuntivo sul client dopo ogni post, poiché viewstate non solo salva gli oggetti per la pagina, ma ricorda gli oggetti se si utilizza il pulsante Indietro. Ciò significa che dopo ogni post indietro viewstate diventa leggermente più grande e più difficile da usare. Esisteranno solo sulla sua pagina fino a quando il browser non passerà a un'altra pagina.

Ogni volta che memorizzo un ID nella pagina in questo modo, creo sempre una proprietà

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

o

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

In questo modo se decidi di cambiarlo da Viewstate in una variabile di sessione o in un campo modulo nascosto, è solo un caso di cambiarlo nel riferimento alla proprietà, il resto della pagina può accedere alla variabile usando " Page.CustomerID " ;.

Answer 3

ViewState è un'opzione. È valido solo per la pagina in cui ti trovi. Non trasporta richieste ad altre risorse come l'oggetto Session.

Anche i campi nascosti funzionano, ma stai perdendo e poche informazioni sulla tua applicazione a chiunque sia abbastanza intelligente da visualizzare la fonte della tua pagina.

Puoi anche archiviare tutto il tuo record in ViewState ed evitare un altro round trip al server.

Answer 4

Personalmente sono molto diffidente nel mettere qualsiasi cosa nella sessione. Troppe volte i nostri processi di lavoro sono andati in bicicletta e abbiamo perso lo stato della sessione.

Mentre descrivi il tuo problema, lo metterei in un campo nascosto o nel viewstate della pagina.

Inoltre, quando si determina dove inserire i dati in questo modo, osservare sempre l'ambito dei dati. È limitato a una singola pagina o all'intera sessione? Se la risposta è "sessione" per noi, la inseriamo in un cookie. (Dichiarazione di non responsabilità: scriviamo app Intranet in cui sappiamo che i cookie sono abilitati.)

Answer 5

Se si tratta di un semplice ID sceglierà di passarlo in querystring, in questo modo non è necessario eseguire postback e la pagina è più accessibile per utenti e motori di ricerca.

Answer 6

Session["MyId"]=myval;

Sarebbe un po 'più sicuro e sostanzialmente offre la stessa meccanica di metterlo in mostra

Answer 7

Tendo ad attaccare cose del genere in campi nascosti, basta fare un po '

 <asp:label runat=server id=lblThingID visible=false />