С ASP.NET viewstate, есть ли лучшая практика, когда в жизненном цикле получить доступ к viewstate? - PullRequest
Новая
       2

С ASP.NET viewstate, есть ли лучшая практика, когда в жизненном цикле получить доступ к viewstate?

2 голосов
/ 08 ноября 2010

При создании пользовательских элементов управления я видел два шаблона для использования состояния просмотра. Одним из них является использование свойств для маскировки доступа к состоянию представления как постоянных данных. 

   public bool AllowStuff
   {
       get
       {
           return (ViewState[constKeyAllowStuff] != null) ?
               (bool)ViewState[constKeyAllowStuff] : false;
       }
       set { ViewState[constKeyAllowStuff] = value; }
   }

Другой - использовать закрытые поля-члены и переопределить методы Load / SaveViewState в элементе управления и обрабатывать их все явно: 

 protected override object SaveViewState()
 {
     object[] myViewState = new object[2];
     myViewState[0] = base.SaveViewState();
     myViewState[1] = _allowStuff;
     return myViewState;
 }

 protected override void LoadViewState(object savedState)
 {
     object[] stateArray = (object[])savedState;
     base.LoadViewState(stateArray[0]);
     _allowStuff = (bool)stateArray[1];
 }

(Я убрал много проверок на безопасность для ясности, так что просто проигнорируй это.)

Есть ли особые преимущества у одного метода над другим? Я не вижу, как они сильно отличаются по производительности. Версия 1 ленивая, поэтому, я думаю, вы сэкономите немного, если вам не нужно это конкретное значение во время прохода. Версия 1 также более абстрактна, детали лучше скрывают. Версия 2 более понятна, когда данные действительно действительны, и их можно читать или изменять (между загрузкой и сохранением), поскольку они более четко работают в жизненном цикле ASP.NET.

Версия 2, как правило, требует большего количества стандартного кода (свойство, вспомогательное приватное поле и обработка состояния представления в двух местах), в отличие от версии 1, которая объединяет все это в одном месте.

Мысли тогда?

Ответы [ 2 ]

2 голосов
/ 08 ноября 2010

Подход частного поля часто используется для объектов, которые не имеют прямого доступа к пакету состояния ViewState.Таким образом, в некотором смысле, я бы использовал первый вариант для пользовательских элементов управления, пользовательских элементов управления или страниц или чего-либо, что имеет ViewState или подобное свойство, но использовал бы другой вариант для объекта, который не имеет прямого доступа к ViewState (например,класс, который вы хотите иметь возможность "сериализовать" и хранить в viewstate).Например, пользовательские элементы управления будут использовать этот подход для хранения состояния дочерних объектов, которые не ссылаются напрямую на представление состояния.

HTH.

1 голос
/ 08 ноября 2010

Во-первых, я бы использовал ControlState, а не viewstate, поэтому он работает правильно, если в контейнере с отключенным состоянием просмотра.

Тогда я бы переопределил init, savecontrolstate, loadcontrolstate и databind.

и убедитесь, что зарегистрировано, что элемент управления использует состояние элемента управления, т.е. Page.RegisterRequiresControlState (this)

oh, и преимущество в том, что ваш элемент управления более устойчив (пользователь не может испортить его так легко) ибудет работать, когда динамически загружен и через постбэки "лучше"

...