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

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

Предыстория этого вопроса:

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

- System.Web.UI.Page 
----- CustomPage1: System.Web.UI.Page 
-------- CustomPage2: CustomPage1
---------- так далее

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

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

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

Источник

3 ответа

Решение

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

Источник

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

Источник

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

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

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