Где я должен реализовать функциональность в объекте Page - конструкторе или OnPreInit? - PullRequest
Новая
       22

Где я должен реализовать функциональность в объекте Page - конструкторе или OnPreInit?

3 голосов
/ 24 февраля 2009

Вопрос, над которым я долго размышлял - будут ли пользователи Stackoverflow часто реализовывать значительную функциональность в конструкторе (в частности, в классах, производных от класса System.Web.UI.Page), или мы должны придерживаться простой логики насколько это возможно, и вместо этого реализовать функциональность в OnPreInit (используя конструктор, чтобы просто создавать экземпляры объектов / значений, которые требуются для функциональности в остальной части страницы для функционирования)? Есть ли подход «наилучшей практики» к этому сценарию?

Справочная информация к этому вопросу:

Система, над которой я работаю, имеет довольно глубокую иерархию страниц - есть около 10 связанных объектов страниц, из которых происходит настоящая страница: 


-- System.Web.UI.Page 
----- CustomPage1 : System.Web.UI.Page 
-------- CustomPage2 : CustomPage1
---------- etc

Каждая страница добавляет определенную часть функциональности, и часто есть либо зависимость от кода, выполняемого в конструкторе пользовательских страниц, либо сама функциональность запускается непосредственно во время построения.

Примером, который лучше всего иллюстрирует мой вопрос, является страница, которая загружает пользовательские объекты из нашей базы данных на страницу, чтобы они были доступны в течение жизненного цикла страницы - во время создания страницы устанавливаются соединения с базой данных, а затем публичные свойства заполняются правильными ценности.

На мой взгляд, это лучше сделать из события OnPreInit, главным образом потому, что мы имеем большую гибкость для выполнения некоторых проверок на уровне страницы (например, если мы хотим предотвратить вызов этой функциональности) до запуска родительской логики (учитывая, что в конструктор порядка выполнения создаст родительские классы перед дочерним классом). С точки зрения ОО, OnPreInit представляется более подходящей областью для реализации этой функциональности - при конструировании страницы следует учитывать конструкцию страницы, задавать любые значения по умолчанию и т. Д., А затем OnPreInit будет использоваться для выполнения любой функциональности, которая требовалась во время Жизненный цикл страницы.

Ответы [ 3 ]

1 голос
/ 24 февраля 2009

В зависимости от реальной функциональности я бы предложил использовать OnInit или OnLoad вместо OnPreInit. OnPreInit был введен для поддержки динамической установки темы или главной страницы, чего вы не сможете сделать позже в жизненном цикле.

1 голос
/ 24 февраля 2009

Я думаю, что ваши рассуждения очень здравы - я согласен, что OnPreInit - правильное место для такой логики.

0 голосов
/ 24 февраля 2009

Имейте в виду, что значения элемента управления не были восстановлены из ViewState OnPreInit, если это обратная передача.

MSDN дает предложения по использованию события . Смотрите «События жизненного цикла». Примеры:

  • PreInit - создание или повторное создание динамических элементов управления
  • Init - используйте это событие для чтения или инициализации свойств элемента управления.
  • Загрузка - используйте метод события OnLoad, чтобы установить свойства в элементах управления и установить соединения с базой данных.
...