Сравним действия, которые совершает ASP.NET 2.0 и ASP.NET 1.0, когда пользователь запрашивает файл с расширением. aspx.
В ASP.NET 1.x среда выполнения анализирует директиву Page страницы, осуществляет поиск соответствующего класса в сборке приложения, затем на основании кода страницы создается класс, производный от класса программной логики страницы. В случае если сборка отсутствует, то осуществляется поиск файла программной логики, указанного в атрибуте Src директивы Page. Если файл найден, то происходит компиляция сборки, если нет, то ASP.NET выбрасывает исключение.
В ASP.NET 2.0 среда выполнения также анализирует директивы Page, осуществляет поиск сборки соответствующей классу логики страницы, после чего создается класс страницы. В отличие от ASP.NET 1.x, родительским классом для класса страницы является System.Web.UI.Page, поскольку создаваемый динамический класс является собственно классом страницы (используются разделяемые классы для класса страницы и класса программной логики), а не потомком класса программной логики. Поэтому, если в ASP.NET 1.x класс Web-формы мог называться также как и сама Web-форма.
<form id="frmDefault" runat="server"></form>
…
public class frmDefault: System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e){}
}
В ASP.NET 2.0 это недопустимо, поскольку элемент управления System.Web.UI.Form является элементом класса.
Основным преимуществом ASP.NET является то, что в случае отсутствия сборки, необходимой для выполнения страницы, происходит компиляция только файла программной логики страницы, без перекомпиляции всей сборки. Поскольку существует динамическая компиляция, то необходимо обеспечить возможность создавать код, общий для всех страниц приложения. Для этой цели в ASP.NET 2.0 существуют специальные директории, являющиеся дочерними директориями корневой директории приложения, одна из которых App_Code, служит для хранения файлов, содержащих общий код для всех страниц. При выполнении динамической компиляции, код из директории App_Code компилируется и становится доступным для всех страниц WEB‑приложения. При этом VS поддерживает код, находящийся в директории App_Code, поэтому работает подсветка синтаксиса и IntelliSense.
Исследовать генерируемые средой выполнения ASP.NET 2.0 файлы, и подробно разобраться в процессе компиляции можно изучив содержимое директории:
%WINDIT%\Microsoft.NET\Framework\версия\Temporary ASP.NET Files\имя_приложения
куда ASP.NET 2.0 помещает динамически созданные сборки. Либо, вызвав ошибку на ASP.NET странице в режиме отладки выбрать ссылку Show Complete Compilation Source.
Если же необходимо заранее скомпилировать проект, перед развертыванием его на сервере в ASP.NET 2.0 существует возможность полной или частичной перекомпиляции WEB‑приложения.
Страница ASP.NET 2.0
5.2.3.1 Директива @Page
Для внесения новых возможностей в ASP.NET 2.0 потребовалось внести изменения и дополнения в класс страницы Page. Поскольку, для установки свойств страницы в design - time используются атрибуты директивы Page, то здесь будут рассмотрены новые атрибуты, появившиеся для реализации механизмов персонализации, шаблонов дизайна, оформления и асинхронной работы станиц. Подробнее о назначении новых атрибутов можно узнать в части пособия, посвященной новым свойствам и методам класса Page. Ниже кратко рассмотрены новые атрибуты директивы Page:
- Async. Указывает на то, какой из интерфейсов IHttpHandler или IHttpAsyncHandler реализует класс страницы. После установки этого атрибута в true, генерируемый динамически класс страницы будет реализовать интерфейс IHttpAsyncHandler, в противном случае класс будет реализовать интерфейс IHttpHandler. Если класс страницы реализует интерфейс IHttpAsyncHandler, то код страницы может выполняться асинхронно до наступления нового события в жизненном цикле страницы PreRender, ко времени наступления которого происходит синхронизация и подготовка HTML-кода для отправки браузеру клиента;
- AsyncTimeOut. Позволяет установить ограничение по времени, отведенное для выполнения асинхронных операций. По умолчанию этот параметр равен 45 секундам;
- Culture. Устанавливает набор региональных параметров (Culture), используемый для страницы;
- EnableTheming. Позволяет включить или выключить поддержку тем оформления. По умолчанию включено;
- MasterPageFile. Указывает путь к шаблону, который будет использован для создания кода этой страницы;
- StyleSheetTheme. Позволяет установить идентификатор темы оформления, которая будет использоваться для изменения установленной темы оформления (в атрибуте Theme или в файле Web.confg).Таким образом, можно установить общую тему оформления для всего сайта, а с помощью атрибута StyleSheetTheme вносить некоторые изменения в общее оформление страницы и/или некоторых элементов управления, содержащихся на странице;
- Theme. Указывает название темы оформления, которая будет использована для оформления кода данной страницы;
- UICulture. Устанавливает набор региональных параметров (Culture), используемый для пользовательского интерфейса страницы.
Жизненный цикл страницы
Жизненный цикл страницы ASP.NET начинается с получения и обработки Web-сервером IIS запроса к данной странице и передачи этого запроса среде выполнения ASP.NET.
В момент получения запроса, среда выполнения:
- загружает класс вызываемой страницы;
- устанавливает свойства класса страницы;
- выстраивает дерево элементов;
- заполняет свойства Request и Response;
- вызывает метод IHttpHandler. ProcessRequest.
После этого среда выполнения проверяет, каким образом была вызвана эта страницы и, если страница вызвана путем передачи данных с другой страницы, о чем будет рассказано далее, то среда выполнения устанавливает свойство PreviousPage.
Стоит отметить также, что помимо рассмотренных ниже этапов выполнения страницы существуют еще и этапы уровня приложения, не специфичные для страницы.
Во время прохождения этапов жизненного цикла возникают события, подписавшись на которые, разработчик может выполнять свой собственный код. Стоит упомянуть атрибут AutoEventWireup, директивы @Page: если этот атрибут установлен в true (значение по умолчанию), то методы класса страницы, названные Page_НазваниеСобытия, автоматически становятся обработчиками соответствующих событий жизненного цикла станицы.
Для того, чтобы проследить жизненный цикл страницы и последовательность возникновения событий, можно установить атрибут Trace директивы @Page в true, а атрибут TraceMode в SortByTime. Тогда в разделе Trace Information можно найти список произошедших событий (колонка Message).
Из всех событий жизненного цикла страницы, разработчик может подписаться только на пять, помимо событий дочерних элементов управления. Эти события: PreInit, Init, Load, PreRender, Unload. Рассмотрим варианты использования этих событий.
Таблица 5.1 – События жизненного цикла страницы
| Событие | Использование |
| PreInit | Во время этого события можно использовать свойство IsPostBack, для того, чтобы определить вызвана ли эта страница в первый раз или в результате постбэка. В плане управления страницей разработчик может: - создавать динамически элементы управления; - динамически устанавливать шаблон дизайна или тему оформления; - считывать или устанавливать свойства объекта Profile. Стоит особо отметить, что на данном этапе, если страница была вызвана в результате постбэка, свойства элементов управления еще не установлены. В случаи, если разработчик самостоятельно установит свойства на этом этапе, на следующем установленные значения могут быть изменены |
| Init | На этом этапе разработчик может считывать или инициализировать свойства элементов управления |
| Load | На этом этапе разработчик может считывать или изменять свойства элементов управления |
| PreRender | Последняя возможность внести изменения во внешний вид страницы |
| Unload | Освобождение занятых ресурсов (закрытие открытых соединений с БД, завершение работы с файлами и т.п.) Важно, что на этом этапе уже создано HTML представление страницы и попытка внести какие-либо изменения (например, вызвав метод Response.Write()), приведет к исключению |
