Jak zdecydować, co przechowywać w stanie oglądania?

Question

Piszę paczkę ogólnych kontrolek ASP.NET, a jedną rzeczą, której nie mogę otoczyć moim umysłem, jest przechowywanie wartości w stanie wyświetlania i kiedy należy założyć, że nie jest to możliwe.

Z jednej strony ma to sens, aby zapisać cały stan kontroli w stan wyświetlania, w tym właściwości, takie jak:

• wartości pola tekstowego wprowadzonych przez użytkownika (lub jakichkolwiek danych formularz)
• opcje konfiguracyjne jak wysokość lub rozmiar strony
• Nawet w jaki sposób formant został skompilowany - na przykład przechowywanie wszystkich danych, z których zbudowany jest widok siatki, lub samej siatki.

Ignorowanie wydajności, tym więcej można przesunąć w stan oglądania, tym lepiej, ponieważ oznacza to, że kontrola będzie zachowywać się dokładnie tak samo w postbackach i nigdy "przypadkowo" nie przywróci wartości lub "zapomni", że została wyłączona. Ale stan wyświetlania nie jest bezpłatny. Przechowywanie wszystkiego oznacza, że ​​formant będzie teraz wyświetlał zarówno HTML, jak i wszystkie jego wewnętrzne właściwości, aby utworzyć ten HTML, który prawie zawsze będzie ponad dwukrotnie większy od danych wyjściowych.

Moje pytanie nie dotyczy wydajności, ale strategii. Na jakich kryteriach decyduję się umieścić nieruchomość w stanie widoku? Myślałam coś wzdłuż tych linii:

Jeśli użytkownik nie może zmienić właściwość, wtedy serwer będzie zawsze ustawić go jawnie, więc jest OK, aby pozostawić go na stan wyświetlania. Nawet dla czegoś takiego jak color=red, użytkownik nie ustawia tej właściwości bezpośrednio; klikną przycisk w innym miejscu, który pośrednio ustawia tę właściwość. Ten przycisk lub jego właściciel powinien zachować stan, a nie kontrolę, która powoduje, że kolor jest czerwony.

Ta logika wskazuje, że tylko właściwości, które powinien przejść do stanu wyświetlania byłoby:

1. Elementy formy jak <input> (iz Request.Form[c.UniqueID] można tego uniknąć wciąż)
2. właściwości, które użytkownik może kontrolować interaktywnie bezpośrednio na sterowanie.

Czy ta logika ma sens? Wydaje się być słaby i chciałbym usłyszeć więcej od ekspertów.

Answer 1

Użyj funkcji ViewState w przypadku spraw, które nie są niezbędne do pracy.

Użyj funkcji ControlState, aby uzyskać rzeczy niezbędne do działania kontrolki, nawet jeśli funkcja ViewState jest wyłączona.

Wartości początkowe i hierarchia kontroli (nawet formanty html) są kompilowane do tymczasowych plików ASP.NET, gdy strona jest najpierw żądana. Więc nie muszą być przechowywane w dowolnym miejscu, gdy nigdy nie zostaną zmienione (a nawet ViewState ich nie zapisze).

Sterowanie zapisuje tylko właściwości w ViewState, które zmieniły się podczas cyklu życia strony (od TrackViewState). Kontrola, który stan został zmieniony, jest "brudny". Na przykład, jeśli zmienisz TextBox1.Text w page_load, ViewState.IsItemDirty("TextBox1.Text") zwróci true. Wartości te będą przechowywane w ViewState.

Wygląd here i here. (Naprawdę polecam przeczytać oba artykuły)

Control State vs. View State Example

Answer 2

Wydaje mi się, że masz rację, martwiąc się o rozdęcie się poziomu widoczności, ale jakie inne opcje są dla ciebie dostępne? Jeśli nie przechowujesz tam danych zmiennych, gdzie go umieścisz? (Możesz rozważyć usunięcie niektórych elementów konfiguracji - może nie pozwolić użytkownikowi na zmianę tak wielu właściwości).

Answer 3

Przeczytaj ten artykuł w witrynie MSDN pokrycie kiedy, gdzie i co używać mnóstwo opcji zarządzania państwowymi dostępne w ASP.NET sekcja stan widoku jest zamieszczona poniżej wygoda - sprawdzając swoje wymagania wobec wad i zalet należy poprowadzić Cię na wykorzystanie w poszczególnych przypadkach:

Cały artykuł tutaj: http://msdn.microsoft.com/en-us/library/z1hkazw7(v=vs.100).aspx

stan wyświetlania Fragment:

View Stan

stron Web Forms zapewnić właściwość ViewState jako wbudowaną w strukturę do automatycznego zatrzymywania wartości pomiędzy wieloma wniosków o samej stronie. Stan widoku jest utrzymywany jako ukryte pole na stronie. Aby uzyskać więcej informacji na temat , zobacz Omówienie zarządzania stanami programu ASP.NET.

Możesz użyć stanu widoku, aby zapisać własne wartości związane z poszczególnymi stronami w czasie przejazdów w obie strony, gdy strona zostanie odesłana do siebie. Na przykład, jeśli twoja aplikacja zachowuje informacje specyficzne dla użytkownika - czyli informacje, które są używane na stronie, ale niekoniecznie są częścią jakiejkolwiek kontroli - możesz przechowywać ją w stanie widoku.

Zalety korzystania z widoku stanu są:

No serwer zasoby są wymagane stan widoku jest zawarty w strukturze w kodzie strony.

Prosta implementacja Wyświetl stan nie wymaga żadnego niestandardowego programowania. Jest on domyślnie włączony, aby zachować dane stanu na kontrolkach .

Rozszerzone funkcje zabezpieczeń Wartości w stanie widoku są mieszane, skompresowane i zakodowane dla implementacji Unicode, co zapewnia większe bezpieczeństwo niż w przypadku ukrytych pól.

Wady przy użyciu widoku stanu są:

Uwagi dotyczące wydajności Ponieważ stan widoku jest przechowywana w samej stronie , przechowywanie dużych wartości może powodować stronę, aby spowolnić kiedy użytkownicy wyświetlić go i kiedy pisać to. Jest to szczególnie istotne w przypadku urządzeń mobilnych, których przepustowość często stanowi ograniczenie.

Ograniczenia urządzeń Urządzenia przenośne mogą nie mieć pojemności pamięci , aby przechowywać dużą ilość danych stanu widoku.

Potencjalne zagrożenie bezpieczeństwa Stan widoku jest przechowywany w jednym lub kilku ukrytych polach na stronie. Chociaż stan widoku przechowuje dane w zaszyfrowanym formacie , nadal można nim manipulować. Informacje ukryte w polu można zobaczyć, jeśli źródło wyjściowe strony jest wyświetlane bezpośrednio, , co stwarza potencjalny problem z zabezpieczeniami. Aby uzyskać więcej informacji, zobacz ASP.NET Bezpieczeństwo aplikacji sieci Web i podstawowe procedury zabezpieczeń dla aplikacji sieci Web .