2009-07-24 7 views
21

Die einzige Möglichkeit, Eigenschaftswerte in einem Benutzersteuerelement beizubehalten, besteht darin, den ViewState zu verwenden.Benutzersteuerelement (Ascx) und Eigenschaften

public string Title { 
     get { return Convert.ToString(ViewState["Title"]); } 
     set { ViewState["Title"] = value; } 
    } 

Ich kann nicht sagen, dass ich mit diesem obwohl echten bin beeindruckt, wie die mehr Eigenschaften ein Benutzer der Kontrolle, desto mehr Mist hat man in der Viewstate stecken würde. Gibt es einen besseren Weg, um Eigenschaften zu erhalten?

+3

Alle Web-Controls machen es auf die gleiche Weise, deshalb wird ViewState riesig ... –

+0

Ich musste am Ende darauf zurückgreifen. Es ist ziemlich frustrierend, wie es funktioniert, aber es macht den Job .. gut für den Moment .. :) –

Antwort

10

Es kommt darauf an. Wenn Sie Eigenschaftswerte benötigen, die über ein Post-Back hinaus bestehen bleiben, müssen Sie entweder ViewState oder Session verwenden. Da diese Steuerelemente auf jedem Post neu erstellt werden, können Sie diesen Status andernfalls nicht wirklich beibehalten.

+0

Ja, die Eigenschaftswerte müssen durch ein Postback persistieren. Ich habe einen Knopf im Benutzersteuerelement, das sein Button-Ereignis auslöst, wenn darauf geklickt wird (duh), und zu diesem Zeitpunkt muss ich bestimmte Eigenschaftswerte abrufen. Naja, schätze ich werde den ViewState einfach aufblähen! – Jagd

+1

"über Post-Back hinaus beibehalten werden, dann müssen Sie entweder ViewState oder Session verwenden". Dies gilt nicht für ViewState. ViewState besteht nur zwischen Post-Backs, nicht darüber hinaus. – dariom

-1

haben Sie versucht, statische Eigenschaften? Denken Sie auch daran, dass http ist zustandslos, so dass Sie nur Ihren Titel auf jedem page_load

+2

Was passiert also, wenn Sie zwei Anforderungen haben und beide unterschiedliche Eigenschaften für das Benutzersteuerelement verwenden möchten? –

2

zurücksetzen kann Es ist nicht so schlimm - das ist so ziemlich genau, wie die eingebauten Steuerelemente arbeiten und im Allgemeinen zu erwartetem Verhalten führen wird. Am besten ist es, ViewState selektiv zu deaktivieren, wenn Sie diese Werte nicht über Postbacks hinweg beibehalten müssen.

Sie könnten auch in ControlState suchen - es ist eine separate "Tasche", die Menschen nicht deaktivieren können, und ist für Dinge wie die GridView wo gibt es einige Dinge, die man nicht über Viewstate ausschalten kann weil es die Kontrolle bricht.

5

Ihr Problem ist genau, was ViewState ist: Um Eigenschaften eines Steuerelements über Postbacks zu erhalten, ist Ihre Lösung also in Ordnung.

Sie könnten es in der Sitzung speichern, aber das belastet wirklich nur den Server. Abhängig von der Anzahl der Benutzer, die Sie haben, könnte dies wirklich schnell hässlich werden.

Denken Sie auch daran, dass Sie ein paar Hauswirtschaft tun müssen, wenn Sie Sitzung verwenden. Wenn Sie beispielsweise Ihr Benutzersteuerelement zweimal auf derselben Seite verwenden möchten, müssen Sie sicherstellen, dass jedes Steuerelement eindeutige Sitzungsvariablen verwendet.

8

Es gibt überhaupt kein Problem mit der Verwendung von ViewState zum Speichern von Eigenschaftswerten für ein Benutzersteuerelement.

Ihre Aussage "Je mehr Eigenschaften eine Benutzerkontrolle hat, desto mehr Mist werden Sie im ViewState festhalten" ist nicht unbedingt wahr. Es ist natürlich möglich, dass ViewState Werte von Eigenschaften für Steuerelemente verfolgt, aber keine Daten in der verdeckten Feldvariablen __VIEWSTATE speichert.

Klingt verrückt, oder? Einen brillanten Artikel über die Funktionsweise von ViewState finden Sie unter TRULY Understanding ViewState.

Es hängt davon ab, wann Sie die Eigenschaften Ihrer Steuerelemente im Lebenszyklus initialisieren. ViewState wird nur in dem ausgeblendeten Feld __VIEWSTATE gespeichert, nachdem die StateBag für ein Steuerelement die Verfolgung von Änderungen an Eigenschaftswerten gestartet hat. Dies geschieht in der OnInit Methode für ein Steuerelement, das zu einem frühen Zeitpunkt des Lebenszyklus ist, aber es gibt Techniken, um Ihre Eigenschaftswerte früher festzulegen, die nicht die Kosten von __VIEWSTATE aufgebläht werden und Ihnen weiterhin alle Vorteile bieten.

Siehe den verknüpften Artikel.Es bespricht alles sehr klar und besser als ich :-)

0

Sie immer die beabsichtigten SaveViewState/LoadViewState Methoden außer Kraft setzen können:

public string Title { get; set; } 

Und dann speichern und laden bei Bedarf:

protected override object SaveViewState() 
{ 
    // Save State as a cumulative array of objects. 
    object baseState = base.SaveViewState(); 

    object[] allStates = new object[2]; 
    allStates[1] = _title; 
    return allStates; 
} 

protected override void LoadViewState(object savedState) 
{ 
    if (savedState != null) 
    { 
     // Load State from the array of objects that was saved during SavedViewState. 
     object[] myState = (object[])savedState; 
     if (myState[0] != null) 
     base.LoadViewState(myState[0]); 

     if (myState[1] != null) 
     _title = (String)myState[1]; 
    } 
}