2008-12-12 5 views
6

Ho la seguente proprietà in un controllo personalizzato:Come mantenere la proprietà Elenco <T> nel controllo personalizzato ASP.NET?

List<myClass> _items; 
public List<myClass> Items{ 
    get { return _items; } 
    set { _items= value; } 
} 

Nel mio codebehind, ho aggiungere elementi alla raccolta come in ...

myCustomControl.items.Add(new myClass()); 

Tuttavia, queste non vengono mantenute attraverso postback. Qual è il modo corretto per consentire la persistenza nei controlli personalizzati?

risposta

1

se si sta parlando di mantenere i dati tra i postback della stessa pagina, è possibile aggiungere manualmente gli elementi a ViewState e recuperarli al caricamento.

+0

Finché List <> e myClass sono contrassegnati Serializable che funzionerà bene. In caso contrario, dovrà ignorare SaveViewState e LoadViewState. –

1

È possibile memorizzarle nei controlli ViewState

public List<myClass> Items{ 
    get { return this.ViewState["itemsKey"] } 
    set { this.ViewState["itemsKey"]= value; } 
} 
+0

Anche in questo caso, MyClass deve essere serializzabile per archiviarlo in ViewState. –

+0

Devi trasmettere il tuo valore di ritorno nel get {}. ViewState è di tipo Object, non di tipo List . – andleer

6

Yikes! Non mettere un elenco <> nel ViewState! Sarà enorme!

Se si aggiunge una stringa < > che contiene due elementi - "abc" e "xyz" nel ViewState, aumenterà di 312 byte.

Se invece si aggiunge una stringa [] che contiene gli stessi due elementi, crescerà solo di 24 byte.

E questo è solo un elenco di stringhe! Puoi inserire le tue classi lì come suggerisce Corey Downie, ma il tuo ViewState fungerà da fungo!

Per mantenere una dimensione ragionevole, dovrai impegnarti a convertire l'elenco di elementi in array di stringhe e viceversa.

In alternativa, è possibile inserire gli oggetti nella Sessione: in questo modo gli oggetti verranno archiviati sul server, anziché essere serializzati in ViewState e inviati al browser e viceversa.

+1

La memorizzazione degli articoli in sessione è probabilmente peggiore rispetto alla memorizzazione in ViewState. Ora hai il problema aggiuntivo di richiedere sessioni adesive in una web farm. –

+0

concordato. Le sessioni sono veramente limitate (anche se sono molto utili quando * puoi * usarle). – teedyay

1

Accetto che ci sono problemi con un elenco <> in viewstate ma funziona. Nota che non c'è setter su questo design. È necessario un riferimento all'oggetto oggetto elenco e il metodo get può creare un nuovo elenco quando necessario.

protected List<myClass> Items 
{ 
    get 
    { 
     if (ViewState["myClass"] == null) 
      ViewState["myClass"] = new List<myClass>(); 

     return (List<myClass>)ViewState["myClass"]; 
    } 
} 
2

Un modo per superare il problema dimensioni con un elenco generico è a persistere nel ViewState come il suo tipo di matrice di base:

protected List<string> Items 
{ 
    get 
    { 
     if (ViewState["Items"] == null) 
      ViewState["Items"] = new string[0]; 
     return new List<string>((string[])ViewState["Items"]); 
    } 
    set 
    { 
     ViewState["Items"] = value.ToArray(); 
    } 
} 
+3

Chris, funzionerà quando si assegna un elenco alla proprietà (list.Add ("abc"); Items = list;) ma non riuscirà a mantenere un elenco che viene modificato utilizzando quanto segue: Items.Add ("abc"); Questo non è molto intuitivo. – andleer

Problemi correlati