Класс Page

ASP.NET --- Основы ASP.NET --- Класс Page

Теперь, когда вы увидели, что собой представляет жизненный цикл страницы, и узнали, каким образом в странице содержатся элементы управления, не помешает указать, что экземпляр самой страницы тоже создается в виде объекта элемента управления. В действительности все веб-формы фактически являются экземплярами класса Page из ASP.NET, который находится в пространстве имен System.Web.UI.

Вы наверняка уже догадались об этом, заметив, что каждый класс отделенного кода явно наследуется от System.Web.UI.Page. Это означает, что каждая создаваемая веб-форма сразу же получает огромный объем функциональности, такой как уже встречавшийся ранее метод FindControl() и свойство IsPostBack. Помимо этого, наследование от Page также еще предоставляет коду доступ к следующим чрезвычайно полезным свойствам:

• Session

• Application

• Cache

• Request

• Response

• Server

• User

• Trace

Многие из этих свойств соответствуют внутренним объектам, которые можно было использовать в классических веб-страницах ASP. Однако в классической версии ASP доступ к этой функциональной возможности получался с помощью встроенных объектов, которые были доступны всегда. В ASP.NET каждый из этих встроенных объектов фактически соответствует свойству Page, которое предоставляет экземпляр полнофункционального класса.

Более подробно об этих объектах рассказывается в последующих разделах.

Объекты Session, Application и Cache

Объект Session является экземпляром класса System.Web.SessionState.HttpSessionState. Он предназначен для хранения любого типа пользовательских данных, который должен постоянно существовать между запросами веб-страниц. Объект Session предоставляет словарный доступ к набору пар "имя-значение", представляющему пользовательские данные для этого сеанса. Состояние сеанса часто применяется для обслуживания информации наподобие имени и идентификатора пользователя, покупательской тележки либо других элементов, удаляемых, когда пользователь уже не посещает страницы веб-сайта.

Объект Application является экземпляром класса System.Web.HttpApplicationState. Подобно объекту Session, он тоже представляет собой словарь данных типа "имя-значение". Однако эти данные являются глобальными для всего приложения.

Что касается объекта Cache, то он является экземпляром класса System.Web.Caching.Cache. В нем также хранится глобальная информация, но он предлагает более масштабируемый механизм хранения, поскольку ASP.NET может удалять объекты в случае нехватки памяти сервера. Как и другие наборы состояний, это, по сути, коллекция объектов "имя-значение", однако здесь для каждого элемента можно также устанавливать специализированные политики истечения срока и определять зависимости.

Выбор способа реализации управления состоянием является одной из ключевых задач разработки веб-приложения.

Объект Request

Объект Request является экземпляром класса System.Web.HttpRequest. Этот объект представляет значения и свойства HTTP-запроса, который привел к загрузке страницы. В нем содержатся все параметры, касающиеся URL, а также все остальные данные, которые были отправлены клиентом. Большая часть из предоставляемой объектом Request информации заключена в оболочку абстракций более высокого уровня (например, в оболочку модели веб-элементов управления ASP.NET), поэтому она даже и близко не так важна, как это было в классической ASP-разработке.

Тем не менее, объект Request все равно может использоваться, например, для выяснения того, каким браузером пользуется клиент, или же для создания cookie-наборов и последующего изучения их содержимого.

В таблице ниже перечислены некоторые наиболее часто применяемые свойства объекта Request:

Объект Response

Объект Response является экземпляром класса System.Web.HttpResponse и представляет ответ веб-сервера на запрос клиента. При классической ASP-разработке объект Response был единственным способом программной отправки HTML-текста клиенту.

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

В следующей таблице перечислены некоторые наиболее часто применяемые члены класса HttpResponse:

Перемещение между страницами

Самой важной функцией класса HttpResponse является предоставление небольшого набора методов, которые позволяют переходить с одной страницы на другую. Наиболее универсальным из них является метод Redirect(), который позволяет перенаправлять пользователя на другую страницу. Ниже приведен пример его применения:

// Перенаправление к файлу в текущем каталоге. 
Response.Redirect("PageFlow.aspx"); 
        
// Перенаправление на другой веб-сайт. 
Response.Redirect("http://www.google.com");

Метод Redirect() требует полного цикла отправки. По сути, он отправляет браузеру сообщение, которое заставляет его запросить новую страницу.

Метод Redirect() имеет перегруженную версию, которая принимает во втором параметре булевское значение. Это значение указывает, должен ли код страницы продолжить выполнение. По умолчанию, несмотря на то, что Redirect() перенаправляет пользователя и закрывает соединение, любой оставшийся код в методе по-прежнему будет выполняться вместе с остальными событиями страницы. Это позволяет при необходимости провести очистку. Но если во втором параметре передается значение true, ASP.NET немедленно прекратит обработку страницы, что потенциально сокращает рабочую нагрузку веб-сервера.

Если нужно переместить пользователя на другую веб-форму внутри того же самого веб-приложения, можно воспользоваться более быстрым подходом с помощью метода Server.Transfer(). Однако этот метод обладает некоторыми особенностями. Из-за того, что перенаправление происходит на стороне сервера, в окне клиентского веб-браузера остается исходный URL-адрес. По сути, у браузера нет никакой возможности узнать, что в действительности он отображает уже другую страницу. Это ограничение приводит к возникновению проблем, когда клиент обновляет страницу или устанавливает на ней закладку.

Кроме того, метод Server.Transfer() не умеет передавать управление отличной от ASP.NET странице или веб-странице, находящейся в другом веб-приложении или на другом веб-сайте.

Для перехода с одной страницы на другую доступен еще один прием — межстраничная отправка (cross-page posting). Он позволяет создавать страницу, которая отправляет себя другой странице, что дает возможность передать всю информацию состояния представления и содержимое любых элементов управления.

В ASP.NET 4 в классе HttpResponse появился еще один метод для перенаправления пользователя — RedirectPermanent() . Этот метод делает то же самое, что и Redirect(), т.е. отправляет браузеру сообщение о перенаправлении, указывающее на необходимость запроса новой страницы. Однако вместо кода состояния HTTP 302 (временное перенаправление) он использует код 301 (который обозначает постоянное перенаправление). Для веб-браузеров это отличие роли не играет, но для поисковых систем оно является очень важным. Когда поисковый робот исследует веб-сайт и получает код состояния 301, он обновляет каталог своей поисковой системы, занося в него информацию о новом URL-адресе.

Это значит, что методы Redirect() и RedirectPermanent() должны использоваться очень разными способами. Метод Redirect() необходимо применять для обеспечения обычной навигации и управления потоком выполнения в приложении (например, при прохождении пользователем какого-то процесса проверки), а метод RedirectPermanent() — при запросе старого URL-адреса, который поддерживался ранее, но больше не используется.

Обычно метод Redirect() будет вызываться где-то в коде веб-формы, в то время как метод RedirectPermanent() — в коде приложения, а точнее в методе Application_BeginRequest() внутри файла global.asax. Это позволит управлять всеми постоянными перенаправлениями в одном месте, не сохраняя заглушки для старых страниц. Ниже приведен пример:

protected void Application_BeginRequest(object sender, EventArgs e) 
{ 
   // Веб-приложение больше не содержит страницу about.aspx
   if (Reguest.FilePath == "/about.aspx") 
   { 
       Response.RedirectPermanent("/about/about-Us.aspx"); 
   } 
   
   // (Сюда следует добавить дополнительные перенаправления.) 
} 

Объект Server

Объект Server является экземпляром класса System.Web.HttpServerUtility и предоставляет разнообразные вспомогательные методы и свойства, которые перечислены в таблице:

Метод Transfer() является наиболее быстрым способом перемещения пользователя на другую страницу приложения. При использовании этого метода не происходит полного цикла отправки. Вместо этого механизм ASP.NET просто загружает новую страницу и начинает ее обработку. В результате URL, отображаемый в браузере клиента, не меняется.

MapPath() представляет собой еще один полезный метод объекта Server. Например, предположим, что вы хотите загрузить из текущего виртуального каталога файл по имени info.txt. Вместо того чтобы жестко кодировать путь, вы можете воспользоваться методом Server.MapPath() и с его помощью преобразовать относительный путь к своему веб-приложению в полный физический путь.

Кодирование HTML и URL

Класс Server также содержит методы, преобразующие обычные строки в представление, которое может безопасно использоваться как часть URL или отображаться на веб-странице. Например, предположим, что вы собираетесь отобразить на веб-странице следующий текст:

Тег <p> используется для обозначения абзаца.

При попытке записи этой информации на странице или ее помещении в элемент управления получится следующее:

Тег используется для обозначения абзаца.

Текст <p> не появится, к тому же браузер интерпретирует его как включение абзаца. С целью обхода такого автоматического поведения потребуется преобразовать потенциальные проблемные значения в специальные HTML-эквиваленты. Например, < превратится в &lt; в окончательной HTML-странице, а браузер отобразит этот символ как <. Полную таблицу преобразований символов в HTML-эквиваленты можно найти по адресу www.arininav.ru/js/entities.htm.

Ниже показан пример обхода проблемы с помощью метода Server.HtmlEncode():

Label1.Text = Server.HtmlEncode("Тег <p> используется для обозначения абзаца.");

Некоторые элементы управления обходят эту проблему, автоматически кодируя дескрипторы. (Веб-элемент управления Label не является одним из них. Вместо этого он позволяет вставлять HTML-дескрипторы любым желаемым образом.) Например, базовый набор серверных элементов управления HTML содержит дескрипторы InnerText и InnerHtml. При установке содержимого элемента управления с использованием InnerText все специальные символы автоматически преобразуются в свои HTML-эквиваленты. Однако это не поможет, если вы пожелаете установить дескриптор, содержащий смесь встроенных дескрипторов HTML и закодированных символов.

Метод HtmlEncode() особенно полезен, если вы извлекаете значения из базы данных и не уверены, является ли текст допустимой HTML-разметкой. С помощью метода HtmlDecode() можно привести текст в нормальную форму, если необходимо выполнять над ним дополнительные операции или сравнения в коде.

Подобным образом метод UrlEncode() преобразует текст в форму, которая может использоваться в URL, отменяя пробелы и другие спецсимволы. Это действие обычно производится над информацией, которая должна быть добавлена в строку запроса.

Следует отметить, что метод HtmlEncode() не преобразует пробелы в неразрываемые пробелы. Это означает, что если имеется последовательность символов пробела, браузер отобразит только один пробел. Этот эффект нежелателен, несмотря на то, что он не влияет на HTML-разметку. Для изменения такого поведения можно заменить пробелы неразрываемыми пробелами вручную с помощью метода String.Replace(). Просто удостоверьтесь, что это действие выполняется после кодирования строки, а не перед ним, или же последовательность фиксированных пробелов ( ) будет заменена символами и трактоваться как обычный текст:

// Закодировать недопустимые символы. 
line = Server.HtmlEncode(line); 
// Заменить пробелы неразрываемыми пробелами. 
line = line.Replace(" ", " ");

Подобным образом метод HtmlEncode() не преобразует разрывы строк в дескриптор <br>. Это означает, что жесткие возвраты каретки будут игнорироваться до тех пор, пока вы специально не вставите дескрипторы <br>.

Проблема правильной кодировки ввода более важна, чем просто проверка правильного отображения данных. Если вы попытаетесь отобразить данные, включающие дескрипторы <script>, вы неумышленно выполните блок JavaScript-кода на машине клиента.

Объект User

Объект User представляет информацию о пользователе, запрашивающем веб-сервер, и позволяет проверить принадлежность этого пользователя к роли.

Объект User реализует интерфейс System.Security.Principal.IPrincipal. Определенный класс зависит от используемого типа аутентификации. Например, пользователя можно аутентифицировать на основе информации об учетной записи Windows с использованием IIS или же с помощью специальной базы данных и выделенной страницы входа в систему. Однако важно понимать, что объект User предоставляет полезную информацию только в том случае, если веб-приложение выполняет какую-то разновидность аутентификации, которая ограничивает доступ анонимных пользователей.

Объект Trace

Объект Trace является универсальным-объектом трассировки (и экземпляром класса System.Web.TraceContext). Он позволяет записывать информацию в журнал на уровне страниц. Этот журнал содержит подробную информацию о синхронизации, чтобы вы не только могли видеть объект Trace для отладки, но и использовать его для мониторинга производительности и синхронизации. Более того, журнал трассировки также содержит набор разнообразной информации, организованной в несколько разделов.

Ниже описана вся информация, которую вы увидите:

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

Вдобавок трассировка предлагает несколько возможностей, которые отсутствуют в отладке, например, отображение объема информации в состоянии представления и время, ушедшее на обработку страницы на сервере. Трассировка также функционирует независимо от того, разрабатываете вы свое приложение в режиме отладки (с символами отладки) или же в режиме окончательной версии.

Трассировку можно включить двумя способами. В любом месте кода можно установить свойство Trace.IsEnabled в true:

Trace.IsEnabled = true;

Обычно это делается в обработчике событий Page.Load. Другой возможностью является использование атрибута Trace в директиве Page:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="ControlTree.aspx.cs" Inherits="ControlTree" 
     Trace="true" TraceMode="SortByCategory" %>

По умолчанию события трассировки перечисляются в том порядке, в котором они генерируются. В качестве альтернативы можно указать, что сообщения следует отсортировать по категории, воспользовавшись атрибутом TraceMode в директиве Page, как показано выше.

На рисунке ниже показан частичный листинг трассировочной информации:

Вы также можете записывать свою информацию в журнал трассировки (часть журнала трассировки, которая находится в разделе Trace Information) с использованием метода Trace.Write() или Trace.Warn(). Эти методы эквивалентны. Единственное различие заключается в том, что Warn() отображает сообщение красным цветом, что помогает отделить его от других сообщений.

Ниже показан фрагмент кода, записывающего сообщение трассировки в результате щелчка пользователем на кнопке (на примере удаления кнопки из предыдущей статьи):

protected void cmdRemove_Click(object sender, EventArgs e)
{
        Trace.Write("RemoveButton_Click", "Удаление элемента управления");

        // Поиска кнопки в коллекции Page.Controls
        Button foundButton = (Button)Page.FindControl("newButton"); 
        
        // Удаление кнопки. 
        if (foundButton != null) 
            foundButton.Parent.Controls.Remove(foundButton);

        Trace.Write("RemoveButton_Click", "Кнопка удалена");
}

При записи сообщения трассировки автоматически отправляются всем слушателям трассировки. Если трассировка страницы отключена, эти сообщения просто игнорируются. Сообщения трассировки автоматически кодируются в HTML. Это означает, что дескрипторы вроде <br /> и <Ь> отображаются в виде текста, а не интерпретируются как код HTML.

На рисунке можно видеть новые записи в журнале:

Вы не только можете отправлять собственные сообщения трассировки, но и создавать обработчики событий, получающие все сообщения трассировки. Хоть эта технология не особо распространена и является специализированной, ее можно применять для фильтрации сообщений, особо важных во время разработки, и соответствующим образом регистрировать эти сообщения. Потребуется лишь обработать событие Trace.TraceFinished, предоставляющее набор объектов TraceContext, которые отображают все сообщения трассировки.