ASP.NET веб-пользовательский контроль передовой опыт

Question

Я создаю некоторые веб-элементы управления и просто задаюсь вопросом, каков правильный / лучший подход к реализации свойств. В этом примере он представляет собой элемент управления «счетная карта», который должен отображать счет (и он также должен делать другие вещи) .... чтобы упростить задачу, я сделал эти примеры кода очень простыми, но на самом деле мой контроль выполняет другие Кроме того, вы можете указать количество очков, кроме того, чтобы отобразить их в метке: -)

Choice #1
private int _score;
public int Score
{
 get { return _score;  }
 set { _score = value; Refresh(); }
}
public void Refresh()
{
 lblScore.Text = Score;
}


Choice #2:
public int Score {get;set;}
protected void PageLoad(object sender, EventArgs e)
{
Refresh();
}
private void Refresh()
{
 lblScore.Text = Score;
}


Choice #3:
       public int Score
    {
     get { lblScore.Text; }
     set { lblScore.Text = value; }
    }

Так что, конечно, вопрос в том, каков наилучший практический способ реализации свойства Score элемента управления .... :-)

MadSeb

Answer 1

Вариант 1

• Вариант 2 исключен, поскольку не следует связывать инициализацию и функциональность с конкретными событиями страницы в UserControl.Это источник неприятных ошибок, связанных с Page-Lifecycle .Возможно, вы захотите внести изменения после Page_Load (например, в Click-Event кнопки на странице), но уже слишком поздно для неявного Refresh.
• Вариант 3 отсутствует, потому что для простой установки текста Label Вы не хотите, чтобы кто-то помнил, что он должен позвонить Refresh после того, как он установил Score.Но это зависит от того, насколько дорогой « мой элемент управления выполняет и другие вещи с оценкой, помимо отображения в метке ».Если вы часто меняете счет, но не обязательно обновляете его немедленно, я бы сделал Refresh после того, как все инициализации выполнено.

По моему мнению, UserControl должен инкапсулировать сложность, пока он достаточно сохраняет.гибкость и контроль для повторного использования.Не делайте слишком много «волшебных» вещей в фоновом режиме, которые могут вызвать ошибки в различных условиях, которые вы не найдете быстро.Это особенно верно для Setter, который обычно должен устанавливать соответствующую переменную.

Существует два разных варианта использования для UserControl:

1. Повторное использование ,Если ваш элемент управления содержит только несколько элементов управления, но вы хотите использовать его много раз, я бы позволил контроллеру получить / установить свойства и не делать в нем сложных вещей, которые зависят от конкретных условий.Это уменьшит возможность повторного использования.Возможно, вы захотите предоставить понятные методы и события, которые может обработать контроллер.
2. Контейнер .Если ваш элемент управления ведет себя аналогично странице и имеет много элементов управления и функций, он должен делать больше всего сам по себе.Вы хотите предоставить только несколько методов и событий (которые не обязательно обрабатываются).Наиболее важным методом в этом случае будет, например, public void BindData(), который выполняет всю инициализацию после того, как контроллер установил необходимые переменные.Это замена для Choice 2.

Примечание : если ваш счет в любом случае сохраняется в lblScore.Text в виде строки, я бы предпочел использовать свойство Textметка вместо создания другой переменной int (приведите ее к int в получателе).В этом есть то преимущество, что вам не нужно хранить переменную во ViewState вручную, потому что она уже сохранена.На этом пути вам не нужно устанавливать его на каждом постбэке.