Модель программирования

ASP.NET — платформа разработки приложений для Web — включает в себя сервисы, программную инфраструктуру и модель программирования, необходимые для создания приложений масштаба предприятия. Хотя синтаксически ASP.NETсовместима со своей предшественницей Active Server Pages (ASP), на самом деле это совершенно новая, революционная программная среда, ориентированная на быструю разработку Webприложений. Будучи частью платформы Microsoft .NET, ASP.NET позволяет с исключительной легкостью создавать и развертывать расширяемые приложения с компонентной структурой для любого целевого браузера или мобильного устройства.

  ASP.NET 1.1 очень популярна, она используется в тысячах разнообразных проектов. Но создание этой системы — лишь первый этап большого пути, и чем дольше вы с ней работаете, тем больше понимаете, как многого ей еще недостает. Упростив решение множества задач, ASP.NET стала настоящим раем для программистов, перешедших на нее от классической ASP, Internet Server Application Programming Interface (ISAPI) и других Webплатформ. Но ее версия 1.1 лишь подогрела аппетиты разработчиков, показала заманчивые перспективы будущего Webпрограммирования, и после нескольких месяцев ее эксплуатации разработчики уже желали большего — много большего!

  Следующей базовой версией данной платформы  стала ASP.NET 2.0, хотя в ней не вводится никакая новая революционная парадигма программирования. Вы не увидите здесь ни радикально нового подхода к проектированию и написанию кода, ни нового синтаксиса. Тем не менее это крупная веха в развитии технологий Webразработки от Microsoft и для разработчиков, и для архитекторов приложений. В ASP.NET 2.0 переработаны многие классы, и ее внутренняя реализация претерпела ряд существенных изменений. Появилось несколько новых элементов управления, призванных повысить продуктивность разработки, усовершенствован ряд существовавших ранее системных модулей и добавлена группа новых, делающих систему гибкой, настраиваемой, надежной и защищенной. В результате перед ведущими разработчиками и архитекторами открылись новые, более эффективные пути решения множества разнообразных задач, а также разрешения проблем, возникавших при разработке приложений в предыдущей версии ASP.NET. Поэтому, для того чтобы получить максимум преимуществ от использования ASP.NET, желательно изучить всю ее программную модель — набор компонентов, программные средства и инфраструктуру.

  Обзору  этой модели и посвящена данная глава. А начнем мы с анализа базовых  концепций платформы ASP.NET и ее программной  модели.

Что такое ASP.NET

До появления ASP.NET существовали три ведущие технологии и платформы разработки Webприложений: ASP, Java Server Pages (JSP) и Webплатформа с открытым исходным кодом, известная под названием LAMP (Linux, плюс Apache, плюсMySQL, плюс Perl, Python или PHP в качестве языка программирования).             

  Примечание Для полноты картины следует упомянуть и о нескольких платформенно-зависимых низкоуровневых технологиях, на которых основываются ASP и JSP. Первая является расширением ISAPI, а вторая реализована как приложение-сервлет. Расширения ISAPI на платформе IIS и сервлеты в Java-системах позволяют создавать серверные приложения для Web на основе подхода, более близкого к классическому. Согласно этому подходу вы создаете страницу не декларативным способом, сочетая разметку со встроенным кодом, а путем написания программного модуля, который сам формирует ее структуру и затем осуществляет рендеринг страницы.

  Хотя у  каждой из перечисленных платформ имеются  элементы и характеристики, специфические  для конкретного языка и определенной архитектуры, все эти платформы  предназначены для создания интерактивных  страниц, совокупность которых образует Webприложение. Кроме того, все эти платформы в той или иной степени дают разработчику возможность отделить программную логику от структуры страницы путем использования компонентов, за вызов и рендеринг которых отвечает сама страница. Но если не учитывать этой объединяющей цели, все платформы очень отличаются друг от друга, и большинство их различий связано с программной моделью и языками программирования. Например, в JSP определен комплекс классов, которые вместе с JavaBeans составляют эффективную расширяемую модель повторного использования компонентов. Кроме того, JSP поддерживает пользовательские тэги и позволяет разработчику связывать код с их определениями. Наконец, будучи ключевым элементом платформы Java 2 Enterprise Edition (J2EE), JSP ориентирована на использование первоклассного компилируемого языка Java, тогда как на платформах ASP и LAMP применяются языки сценариев. Какое же место среди упомянутых технологий занимает ASP.NET?

  Подобно ASP и всем прочим средам разработки и выполнения Webприложений ASP.NET работает поверх протокола HTTP, используя достоинства этого протокола и его правила для организации двунаправленного взаимодействия между сервером и браузером. От множества других технологий разработки Webприложений ее отличает абстрактная программная модель Web Forms. Кроме того, платформа ASP.NET является интегральной частью Microsoft .NET Framework. А это очень важное обстоятельство. Приложение ASP.NET представляет собой расширяемый набор повторно используемых компонентов. Их код компилируется, причем его можно писать на таких высококлассных языках программирования, как C#,Microsoft Visual Basic .NET, Microsoft JScript .NET и J#, используя при этом иерархию классов .NET Framework.

  Таким образом, ASP.NET соединила в себе все лучшее, что создано в области разработки Webприложений. Семантически (и до некоторой степени в отношении языков программирования) эта система совместима с ASP.NET. Она предоставляет такие же возможности объектноориентированного программирования, как JSP (определение пользовательских тэгов, применение компилируемых языков, создание приложений с компонентной структурой, расширяемость и возможность повторного использования кода). А кроме того, в ASP.NET имеется обширный набор средств, инструментов и системных функций, которые можно объединить под общим названием средства абстрагирования программной модели HTTP. Целый комплекс дружественных к программисту классов позволяет разрабатывать страницы теми же методами, что и при создании настольных приложений. А модель Web Forms обеспечивает реализацию классической модели приложения, управляемого событиями, но с развертыванием через Web.

  ASP.NET поддерживается  на множестве платформ, к числу  которых относятся Microsoft Windows 2000 с Service Pack 2, Windows XP Professional и Windows Server 2003. Для разработки серверных приложений ей требуется WebсерверInternet Information Services (IIS) версии 5.0 или выше, а также пакет Microsoft Data Access Components (MDAC) 2.7, который автоматически устанавливается вместе с .NET Framework. С точки зрения производительности, надежности и защищенности идеальным сочетанием серверного программного обеспечения для хостинга приложений ASP.NET является Windows Server 2003 (лучше всего с Service Pack 1) и IIS 6.0.

Программирование  в эру Web Forms

Идея, положенная в основу модели ASP.NET Web Forms, является результатом поиска наилучшей стратегии дешевого, но эффективного Webвзаимодействия. Все основные достоинства Webприложений и самые существенные их недостатки связаны с протоколом HTTP. Он работает без сохранения состояния, поэтому в приложениях на его основе приходится применять ряд специализированных программных технологий, не требующихся настольным приложениям, и в первую очередь технологии управления состоянием. Однако простота и масштабируемость HTTP, обеспечившие его эффективность, позволили этому протоколу получить всемирное распространение — ведь именно благодаря ему Интернет стал тем, чем он является сейчас. И теперь, когда стремительно возрастает спрос на мощные Webприложения с богатыми возможностями, программистам приходится искать новые пути обеспечения эффективного взаимодействия клиента и сервера.

  Предлагалось  множество технологий, призванных обеспечить связь между разными страницами приложения, а также последовательными  вызовами одной и той же страницы одним клиентом. Большинство программистов  привыкли мыслить категориями выполняемых  на клиенте действий, вызывающих ответные действия на сервере. Однако эта фундаментальная  схема не может быть реализована  в Webсреде непосредственно, без специальных средств, действующих с обеих сторон. Необходимы определенный уровень абстрагирования и системные сервисы, которые обеспечивали бы непрерывность взаимодействия сервера и клиента.

  В ASP (в  большей степени, нежели в JSP) реализован декларативный подход к решению этой задачи; объектная же модель ASP не отличается богатством и разнообразием. Программистам, которые собираются освоить технологию разработкиWebприложений, необходимо научиться мыслить поиному, оставить за порогом привычную парадигму действияответа.

Событийно-управляемое  программирование в HTTP-среде

Программная модель ASP.NET Web Forms привнесла в Web не присущую ей изначально концепцию событийноуправляемого взаимодействия. Для реализации этой концепции нужно, чтобы данные, связанные с действиями пользователя на клиентском компьютере, передавались на сервер — это обязательное условие осуществления работы приложения с сохранением состояния. Сервер обрабатывает информацию о действиях клиента и генерирует ответные действия. Общее состояние приложения включает информацию двух типов: состояние клиента и состояние сеанса. Состояние клиента — это главным образом содержимое полей формы, которое именуется состоянием страницы. Доступ к нему осуществляется посредством серверных коллекций, в которых хранятся данные, полученные в результате возврата формы. Но как обстоит дело с общим состоянием сеанса? Пользователь ожидает, что информация, отправленная серверу с одной страницы, будет использована на следующих страницах, которые с ней логически связаны. Возьмем, к примеру, приложение для электронной коммерции, в котором пользователь наполняет корзину для покупок. Какой компонент этого приложения помнит, что именно пользователь положил в свою корзину? Сам по себе протокол HTTP не дает возможности отслеживать подобную информацию. Поэтому необходима дополнительная серверная инфраструктура, надстроенная поверх данного протокола и отвечающая за сохранение состояния сеанса.

  Разработчику Webприложений исключительно важно понимать суть концепции программирования без сохранения состояния сеанса. Мы говорили, что такова природа протокола HTTP, в котором два последовательных запроса, направленных клиентом серверу, никак не связаны друг с другом и обрабатываются сервером совершенно независимо. Он даже не знает, что они пришли от одного и того же клиента в ходе одного сеанса работы с приложением, и не сохраняет никакой информации, связанной с этим сеансом. Единственным связующим звеном запросов может быть информация приложения, сохраняемая в глобальных объектах. В ASP.NET типичным методом обхода описанного системного ограничения является применение реентерабельных форм. Реентерабельная форма — это HTMLэлемент <form>, выполняющий возврат данных формы той странице, которая его содержит. Сами по себе такие формы не решают проблему, однако в сочетании с блоками кода и скрытыми полями, где хранится важная для страницы информация состояния, они позволяют это сделать разработчикам, причем весьма элегантно.

  Такое решение  стало стандартным, интегрированным  в исполняющую среду ASP.NET, и теперь именно таким способом все приложения ASP.NET сохраняют свое состояние. Возможность сохранения состояния страницы между запросами обеспечивает исполняющая среда ASP.NET. Генерируя HTMLкод определенной страницы, ASP.NET кодирует состояние серверных объектов и помещает его в несколько скрытых, прозрачно создаваемых полей формы. Когда поступает запрос на предоставление данной страницы, исполняющая среда анализирует включенную в состав запроса информацию состояния (содержимое скрытых полей формы той клиентской страницы, от которой поступил запрос) и учитывает ее при формировании новых экземпляров серверных объектов. Схема описываемого процесса представлена на рис. 1-1. Как видите, он очень отличается от процесса работы приложений Windows Forms.

Рис. 1-1. Сравнение моделей Windows Forms и Web Forms из .NET Framework

  Модель Windows Forms основана на классическом событийноуправляемом стиле программирования настольных приложений. Каким бы ни было соединение между клиентскими и серверными компонентами, сервер всегда реагирует на клиентский ввод и ему известно состояние приложения. А само приложение является двухслойным, причем его слои тесно связаны между собой. Модели Web Forms для поддержки такой событийноуправляемой схемы работы требуется некий дополнительный механизм. На рис. 1-1 его представляют блоки десериализации состояния страницы, выполняемый при получении запроса, и сериализации состояния страницы, выполняемый при подготовке ответа.

  За выполнение обеих операций отвечает исполняющая  среда ASP.NET — дополнительный код, который специальным образом расширяет возможности Webсервера. Реентерабельные формы и скрытые поля являются низкоуровневыми средствами, используемыми при работе с состоянием. Такая схема работы не была бы достаточно эффективной, если бы для ее поддержки не создали богатую объектную модель, охватывающую весь контент серверной страницы. Эта объектная модель — ключевой элемент платформы ASP.NET.

  Компонентная  модель ASP.NET идентифицирует и описывает  строительные блоки страниц ASP.NET. Она  реализована как объектная модель, где практически каждый HTMLэлемент страницы (речь идет о тэгах типа <form> или <input>) имеет свой серверный аналог. Кроме того, объектная модель ASP.NET включает множество компонентов — так называемых серверных элементов управления, или Webэлементов, которые представляют более сложные части пользовательского интерфейса. Многим из этих элементов управления соответствуют не отдельные HTMLэлементы, а их сочетания. Типичными примерами являются элементы управления Calendar и DataGrid.

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

  Знакомство  с платформой ASP.NET имеет смысл  начать с компонентной модели ASP.NET. С нею вы будете иметь дело на протяжении всего цикла разработки, от проектирования страниц до конфигурирования исполняющей среды (рис. 1-2).

Рис. 1-2. Общая схема стека разработки ASP.NET (стрелка указывает направление  
от пользовательского интерфейса к системным сервисам)

  Прежде  чем перейти к подробному описанию представленных на рис. 1-2 элементов, мы рассмотрим основные принципы работы протокола HTTP, в соответствии с которым осуществляется взаимодействие компонентов приложения, а после этого поговорим о структуре страницы ASP.NET и о том, как на данной платформе создаются и развертываются приложения.

Протокол HTTP

В этом разделе  приводится краткий обзор базовых  принципов функционирования Webприложений. Если вы уже знакомы с основами работы Web, то можете пропустить его и сразу переходить к следующему разделу.

  Аббревиатура HTTP настолько хорошо всем знакома и мы так к ней привыкли, что многие из нас уже не помнят, что она означает. Поэтому прежде всего напомню: HTTP является сокращенным названием протокола передачи гипертекста — Hypertext Transfer Protocol. Это текстовый протокол, который определяет, как взаимодействуют между собой браузеры и серверы Web. Формат пакета HTTP описан в документе RFC 2068, который можно загрузить по адресуhttp://www.w3.org/Protocols/rfc2068/rfc2068.txt. Пакеты HTTP передаются через соединение TCP (Transmission Control Protocol — протокол управления передачей), а местом их назначения является стандартный порт 80 компьютера, расположенного по целевому IPадресу (IP, Internet Protocol — протокол Интернета).

Запрос HTTP

Когда вы задаете URL в адресной строке браузера, последний, используя систему доменных имен (Domain Name System, DNS), транслирует указанное в составе URL имя сервера в его IPадрес. Браузер открывает сокет и соединяется с портом 80, расположенным по данному адресу. Ниже приведен пример простейшего запроса на получение страницы, URL которой является http://www.contoso.com/default.aspx:

GET /default.aspx HTTP/1.1 
Host: www.contoso.com

  Первая  строка текста запроса — это так называемая стартовая строка (start line). Она должна содержать имя подлежащей выполнению команды HTTP (в данном случае GET), URL ресурса и номер версии протокола HTTP, которую решил использовать клиент.

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

§ UserAgent — идентифицирует тип браузера, направившего запрос.

§ Connection — указывает, как серверу следует поступить с подключением: закрыть его или оставить активным.

§ IfModifiedSince — используется для проверки клиентом того, является ли действительным содержимое кэша.

  Наиболее  распространенными командами HTTP, также называемыми глаголами HTTP, являются GET и POST. Команда GET позволяет извлечь информацию, идентифицируемую URL запроса, а команда POST — передать включенный в запрос контент серверу для обработки. Обычно глагол POST используется для отправки серверу определенного блока данных, например информации, которую пользователь ввел в размещенную на Webстранице форму.

Ответ HTTP

Ответ сервера  содержит строку состояния, где указывается номер версии протокола и код возврата (успех/неудача выполнения запроса). За строкой состояния следует группа заголовков (они идентифицируют тип контента, определяют его длину, содержат другую информацию), а за ними — тело (контент) ответа, отделенное пустой строкой. Рассмотрим пример простейшего HTMLвывода, возвращенного сервером, у которого клиент запросил страницу ASP.NET:

HTTP/1.1 200 OK 
Server: MicrosoftIIS/5.0 
ContentType: text/html 
ContentLength: 51 
 
<html><body><h1>ASP.NET is cool!</h1></body></html>

  Следует понимать, что запросы и ответы — это текстовые строки, отформатированные в соответствии с правилами HTTP, которые передаются через соединение TCP. Код возврата 200, который вы видите в первой строке приведенного выше ответа, означает, что запрос выполнен успешно. Сервер обработал его и вернул контент определенной длины — 51, имеющий заданный MIMEтип — text/html. (Аббревиатура MIME расшифровывается как Multipurpose Internet MailExtensions — многоцелевые расширения электронной почты в сети Интернет.) Допустимые коды ответов HTTP перечислены в спецификации этого протокола. Пустая строка, отделяющая контент от последнего заголовка, вставлена не для удобства чтения: это обязательная пара символов возврат каретки–перевод строки, присутствия которой в данном месте ответа требует стандарт HTTP.

  Итак, браузер  получает ответ сервера, имеющий  описанную структуру. Что происходит дальше, зависит от MIMEтипа контента ответа и возможностей браузера. Например, контент типа text/html все браузеры выводят одинаково — какHTML, а вот с контентом типа text/xml поступают поразному: одни выводят его в виде обычного текста, тогда как другие (например, Microsoft Internet Explorer 6.0) применяют к нему перед выводом встроенные таблицы стилей.

Построение  серверного слоя абстрагирования

Любое взаимодействие между браузерами и серверами Web заключается в обмене пакетами, подобными только что рассмотренным. Если заданный в запросе URL указывает на HTMLстраницу, сервер обычно считывает содержимое ее файла и просто переписывает его в тело ответа. Если же указана страница ASP.NET, в работу включается особый модуль — ISAPIрасширение IIS.

  ISAPIрасширением называется библиотека динамической компоновки (DLL), зарегистрированная в IIS как обработчик запросов ресурсов с заданным расширением имени файла. Получив запрос ресурса с расширением .aspx, IIS вызывает соответствующее ему ISAPIрасширение. Оно анализирует запрос и конфигурирует серверную среду, которая будет формировать ответ для браузера. После извлечения связанных с запросом данных состояния и выполнения ряда других необходимых операций активизируется .aspxстраница, которая и формирует HTMLвывод.

Возврат формы

Единственным  элементом клиентской страницы, который  может передавать данные серверу, является HTMLтэг <form>. Когда пользователь щелкает расположенную в форме кнопку типа submit, браузер собирает содержимое всех элементов управления этой формы в одну строку и передает ее серверу в составе команды GET или POST. Ниже приведено определение простейшей HTMLформы, содержащей текстовое поле и кнопку типа submit:

<form method="post" action="default.aspx"> 
    <input type="text" name="EmpCode" /> 
    <input type="submit" value="Send" /> 
</form>

  Здесь указано, что введенные в форму данные должны передаваться серверу с помощью команды POST, и задан целевой URL соответствующего запроса — default.spx. Ниже продемонстрирован запрос с командой POST, который будет сгенерирован, когда пользователь щелкнет submitкнопку:

POST /default.aspx HTTP/1.1 
Host: www.contoso.com 
ContentType: application/xwwwformurlencoded 
ContentLength: 12 
 
EmpCode=1001

  Обрабатывая этот запрос, расширение ISAPI проанализирует его тело и представит содержащуюся в запросе информацию с использованием дружественной к программисту объектной модели. Переменная EmpCode будет представлена не строкой имязначение, а элементом коллекции Request.Form, определенной на уровне приложения. Это первый уровень абстракции, надстроенный поверх программной модели HTTP. Такие объекты, как Request, Response и Server, образуютHTTPконтекст запроса. Они поддерживаются большинством платформ разработки Webприложений, включая JSP и ASP. Однако в ASP.NET существует и ряд других полезных системных объектов.

Структура файла страницы ASP.NET

Страница ASP.NET представляет собой серверный текстовый файл с расширением .aspx. Он имеет модульную структуру и состоит из трех разделов: директив страницы, ее кода и пользовательского интерфейса.

§ Директивы страницы Раздел предназначен для конфигурирования окружения, в котором будет выполняться страница, и определения способа обработки страницы исполняющей средой ASP.NET. Кроме того, эти директивы позволяют сделать относительно страницы определенные предположения. С их помощью можно импортировать пространства имен, необходимые для программного кода, загрузить сборки, которые в данный момент отсутствуют в глобальном кэше сборок (Global Assembly Cache, GAC), а также зарегистрировать новые элементы управления с пользовательскими именами тэгов и префиксами пространств имен.

§ Программный код В данном разделе размещаются обработчики событий страницы и ее элементов управления, а также вспомогательные подпрограммы. Однако не обязательно, чтобы связанный со страницей программный код находился непосредственно в ее файле — он может храниться и отдельно, в так называемом файле отделенного кода страницы. Если код находится в основном файле страницы, то он должен содержаться в тэге с именем <script>. (Данное имя, которое переводится как «сценарий», не совсем точно отражает назначение тэга, оно было выбрано из соображений обратной совместимости.) Серверные тэги <script> отличаются от одноименных клиентских тэгов наличием атрибута runat=server, о котором я расскажу далее в этой главе. Перед выполнением код страницы обязательно компилируется. Обычно это делается при первом обращении к данной странице. Однако в ASP.NET 2.0 весь код приложения может быть предкомпилирован и развернут в виде двоичных сборок.

§ Интерфейс страницы В этом разделе файла определяется структура страницы. Здесь содержатся серверные элементы управления, литеральный текст и тэги HTML. Для управления пользовательским интерфейсом, генерируемым серверными элементами управления, могут использоваться их атрибуты и свойства.

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

  В главах 2 и 3 мы сможем подробнее рассмотреть структуру и возможности страниц ASP.NET и изучить их строительные блоки.

Демонстрационная  страница ASP.NET

Пришло время  показать вам, как выглядит страница ASP.NET. Простейшие страницы можно создавать  в обыкновенном текстовом редакторе, поэтому откройте Notepad, и пусть спящий великан (я имею в виду Microsoft Visual Studio .NET) пока отдыхает. Приведенный ниже текст составляет простую страницу ASP.NET, которая предоставляет пользователю возможность ввести одно или несколько слов и одним щелчком кнопки перевести их в верхний регистр. Чтобы не усложнять пример, я включил весь необходимый программный код прямо в файл страницы. (Как вы узнаете позже, в реальных приложениях код страниц обычно содержится в отдельных файлах.)

<! Раздел директив > 
<% @Page Language="C#" %> 
 
<! Раздел кода > 
<script runat="server"> 
private void MakeUpper(object sender, EventArgs e) 
{ 
    string buf = TheString.Value; 
    TheResult.InnerText = buf.ToUpper(); 
} 
</script> 
 
<! Раздел пользовательского интерфейса страницы > 
<html> 
<head><title>Pro ASP.NET (Ch 01)</title></head> 
<body> 
<h1>Make It Upper</h1> 
<form runat="server"> 
    <input runat="server" id="TheString" type="text" /> 
    <input runat="server" id="Button1" type="submit" value="Proceed..." 
        OnServerClick="MakeUpper" /> 
    <hr> 
    <h3>Results:</h3> 
    <span runat="server" id="TheResult" /> 
</form> 
</body> 
</html>

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

  Раздел  пользовательского интерфейса страницы состоит из литералов и тэгов HTML, многие из которых содержат упомянутый атрибут runat. Тэги, помеченные данным атрибутом, не являются HTMLэлементами. Это представления серверных компонентов — элементов управления ASP.NET, отвечающих за формирование отправляемой браузеру разметки. Тэги исходного файла ASP.NET, помеченные атрибутом runat, не выводятся в формируемый выходной поток, а проходят сложный процесс трансформации, в результате которого генерируется разметка. За создание экземпляров элементов управления, соответствующих тэгам исходного файла страницы, отвечает исполняющая среда ASP.NET.

Краткий обзор кода страницы

Благодаря атрибуту runat при обработке исходного файла страницы на сервере текстовое поле ввода превращается в экземпляр класса HtmlInputControl. Свойство HtmlInputControl этого класса определяет текст, который по умолчанию будет содержаться в поле. Когда пользователь щелкает submitкнопку, страница автоматически выполняет возврат данных формы самой себе. Чтобы так происходило, необходимо установить атрибут runat тэга <form>. После возврата формы страницей значение поля ввода прочитывается сервером и автоматически присваивается свойству Value новосозданного экземпляра класса HtmlInputControl. Затем выполняется код, связанный с событием OnServerClick. Этот код принимает текущее содержимое текстового поля (возвращенную страницей строку) и переводит ее символы в верхний регистр. Далее эта строка присваивается свойству InnerText серверного элемента управления, связанного с HTMLтэгом <span>. Когда завершается выполнение обработчика события MakeUpper, страница готова для рендеринга — останется лишь отправить обновленный HTMLкод браузеру.

  Для того чтобы протестировать созданную  в данном примере страницу, скопируйте ее .aspxфайл в корневой каталог Webсервера. Обычно это c:\inetpub\wwwroot. При желании вы можете создать произвольный виртуальный каталог. Присвойте странице имя hello.aspx, откройте ее в браузере и щелкните содержащуюся в ней кнопку. Что вы увидите, показано на рис. 13.

Рис. 1-3. Наша первая (совсем простая) страница ASP.NET в действии

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

<! Раздел директив > 
 
<! Раздел кода > 
 
<! Раздел пользовательского интерфейса страницы > 
<html> 
<head><title>Pro ASP.NET (Ch 01)</title></head> 
<body> 
<h1>Make It Upper</h1> 
<form method="post" action="hello.aspx" id="Form1"> 
<div> 
    <input type="hidden" name="__EVENTTARGET" value="" /> 
    <input type="hidden" name="__EVENTARGUMENT" value="" /> 
    <input type="hidden" name="__VIEWSTATE" value="/wEPDwUJNzM4N...==" /> 
</div> 
 
<script type="text/javascript"> 
<! 
var theForm = document.forms['Form1']; 
if (!theForm) { 
    theForm = document.Form1; 
} 
function __doPostBack(eventTarget, eventArgument) { 
    if (!theForm.onsubmit || (theForm.onsubmit() != false)) { 
        theForm.__EVENTTARGET.value = eventTarget; 
        theForm.__EVENTARGUMENT.value = eventArgument; 
        theForm.submit(); 
    } 
} 
// > 
</script> 
 
<input name="TheString" type="text" id="TheString" value="Hello, world" /> 
<input name="Button1" type="submit" id="Button1" value="Proceed ..." /> 
<hr> 
<h3>Results:&nbsp;</h3><span id="TheResult"></span> 
</form> 
</body> 
</html>

  Как видите, в состав тэга <form> включен жестко закодированный атрибут action, обеспечивающий возврат формы той же странице. Он помещается сюда автоматически и играет в ASP.NET очень важную роль. Скрытые поля, которые содержатся в приведенном листинге, также генерируются автоматически — они необходимы для работы механизма возврата формы. Сказанное касается и встроенного кода сценария. Тэги <input> почти идентичны своим аналогам из исходного файла .aspx, из них лишь исчез атрибут runat.

  Ну а  теперь давайте рассмотрим те программные  слои ASP.NET, которые обеспечивают функционирование страниц в составе приложений.

Компонентная  модель ASP.NET

ASP.NET является базовой технологией всей связанной с Web функциональности .NET Framework. Сама .NET Framework представляет собой иерархию классов, охватывающих все аспекты программирования для операционной системыWindows. Webприложение состоит из страниц, которые пользователь запрашивает у сервера, а сервер обрабатывает, чтобы вернуть код разметки, главным образом состоящий из HTMLкода. Способ обработки запрошенного ресурса и генерирования разметки зависит от конкретного сервера. Если ресурс имеет расширение .aspx, IIS поручает его обработку исполняющей среде ASP.NET.

  Исполняющая среда ASP.NET преобразует исходный код  запрошенной страницы .aspx в «живой» экземпляр класса .NET Framework, наследующего базовый класс с именем Page. Выполняющаяся страница ASP.NET — это объект; объектами являются и все ее компоненты, то есть серверные элементы управления.

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

Модель  взаимодействия компонентов

Любому элементу страницы ASP.NET, помеченному атрибутом runat, можно присвоить уникальный идентификатор, который позволяет обращаться к этому элементу из серверного кода. Доступ к элементам по идентификаторам естественен для клиента (именно так работают страницы с динамическим HTML), но для серверных приложений это нечто совершенно новое. Реализация такого революционного подхода стала возможной благодаря двум факторам:

§ компонентной архитектуре платформы .NET, составной частью которой является ASP.NET;

§ встроенному в ASP.NET механизму управления состоянием приложения.

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

  Все элементы страницы являются полноценными компонентами, а не просто анализируемым текстом. Такая модель страницы обладает исключительной мощью и гибкостью. Для создания нового элемента управления достаточно создать новый класс, производный  от одного из существующих. А для  построения иерархии наследования страницы достаточно задать для нее родительский класс, отличный от базового класса Page.             

  Внимание! Если каждому элементу управления страницы ASP.NET явно не присвоить уникальный идентификатор, Visual Studio .NET 2005 вернет ошибку времени разработки, что, однако, не помешает успешному выполнению этой страницы.

Атрибут runat

Атрибут runat определяет, как должен обрабатываться элемент страницы: выводиться как есть на этапе рендеринга или преобразовываться в экземпляр определенного класса .NET, сохраняющий свое состояние. Такой класс сам отвечает за вывод необходимой разметки. Все элементы разметки, атрибуту runat которых присвоено значение server, интерпретируются как серверные элементы управления. Классы таких элементов управления имеют свойства и методы, позволяющие конфигурировать их состояние. Во время подготовки отправляемого браузеру ответа элемент управления генерирует необходимый HTMLкод. Рассмотрим следующую простую команду, которая выводит в составе клиентской страницы якорный элемент:

Response.Write("<A id=myAnchor href=www.asp.net>Click me</A>")

  В данном случае якорный элемент создается  программным способом, а не определяется в разметке страницы. В классической ASP блоки кода и метод Response.Write являются единственными средствами, с помощью которых можно динамически создавать и конфигурировать элементы управления. В некоторых средах разработки, например в Microsoft Visual InterDev, поддерживаются элементы управления времени разработки, позволяющие выводить динамически генерируемый HTMLкод объектным способом. Однако они предназначены только для генерирования разметки и кода сценариев во время разработки (о чем и говорит их название). В ASP.NET появилось совершенно новое семейство элементов управления, которые можно назвать элементами управления времени выполнения, подчеркнув тем самым их принципиальное отличие от элементов управления времени разработки.

Работа  с серверными элементами управления

При создании страницы ASP у вас нет возможности программно управлять элементом myAnchor. На сервере это фиксированный, безжизненный текст, годящийся лишь для отправки браузеру, и только на клиенте он оживает и может выполнять инструкции сценария. Предположим, что вам нужно установить атрибут href якоря с учетом условий времени выполнения. В классической ASP для этого сначала пришлось бы получить или сформировать значение, предназначенное для присвоения атрибуту, а затем вызвать метод Response.Write:

strHref = "www.asp.net" 
strHtml = "<A id=myAnchor " 
strHtml = strHtml + "href=" + strHref 
strHtml = strHtml + ">Click me</A>" 
Response.Write(strHtml)

  Приведенный код будет работать и в составе  страницы ASP.NET, но в данном случае это  не лучшее решение. Объявив тэг <A> с атрибутом runat, якорный элемент можно оживить прямо на сервере:

<A runat="server" id="myAnchor">Click me</A>

  Загрузив  запрошенную браузером страницу, исполняющая среда ASP.NET производит разбор ее исходного кода и создает  экземпляры всех элементов управления, помеченных атрибутом runat. В пределах страницы экземпляр серверного элемента управления, созданного для тэга <A>, идентифицируется именем myAnchor. Для программной установки атрибута href после загрузки страницы может использоваться такой код:

<script runat="server" language="C#"> 
void Page_Load(object sender, EventArgs e) 
{ 
    myAnchor.HRef = "http://www.asp.net"; 
} 
</script>

  Элементам разметки из файла .aspx, имена которых совпадают с именами элементов HTML, ставятся в соответствие серверные элементы управления. Однако не у всех тэгов HTML имеются аналоги среди серверных элементов управления ASP.NET. Для тех тэгов, которым специальные элементы управления не сопоставлены, используется универсальный элемент управления. Список тэгов и соответствующих им элементов управления жестко закодирован в исполняющей среде ASP.NET. Элементам разметки, принадлежащим к пространству имен <asp:>, сопоставляются серверные элементы управления, а остальным ставятся в соответствие сборка и класс, объявленные с использованием директивы @Register.

Тэги  уровня страницы

Атрибут runat может использоваться в таких тэгах уровня страницы, как <head> и <body>. Эти тэги представлены экземплярами класса HtmlGenericControl.

  HtmlGenericControl — это класс .NET, который ставится в соответствие серверным тэгам HTML, не имеющим представлений среди специализированных классов .NET Framework. Список таких тэгов включает, в частности, <span>, <font> и<iframe>.

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

<%@ Page Language="C#" %> 
<script runat="server"> 
private void Page_Load(object sender, EventArgs e) 
{ 
    TheBody.Style[HtmlTextWriterStyle.BackgroundColor] = "lightblue"; 
} 
</script> 
<html> 
<body id="TheBody" runat="server"> 
    <h3>The background color of this page has been set programmatically. 
        Open View|Source menu to see the source code.</h3> 
</body> 
</html> 
The resulting HTML code is as follows: 
<html> 
<head><title>Pro ASP.NET (Ch 01)</title></head> 
<body id="TheBody" style="backgroundcolor:lightblue;"> 
<form method="post" action="Body.aspx" id="Form1"> 
    <div> 
        <input type="hidden" name="__VIEWSTATE" value="/wEPD... RVC+" /> 
    </div> 
    <h3>The background color of this page has been set programmatically. 
        Open View|Source menu to see the source code.</h3> 
</form> 
</body> 
</html>

  Аналогичным образом можно установить любые  атрибуты тэга <body>, скажем, выбрать программным способом таблицу стилей или фоновое изображение. Для установки внутреннего текста тэга используется свойство InnerText, а для создания атрибутов тэга — коллекция Attributes класса HtmlGenericControl:

TheBody.Attributes["Background"] = "/proaspnet20/images/body.gif";

  Подробнее о программном интерфейсе класса HtmlGenericControl мы поговорим в главе 4.            

  Примечание В ASP.NET 2.0 содержимое тэга <head> доступно программно лишь при условии, что он помечен атрибутом runat. У класса Page имеется набор специализированных свойств и методов, которые будут рассмотрены в главе 3.

Неизвестные тэги

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

<%@ Page Language="C#" %> 
<script runat="server"> 
void Page_Load(object sender, EventArgs e) 
{ 
    dinoe.Attributes["FavoriteFood"] = "Tbone steak"; 
} 
</script> 
<html> 
<head><title>Pro ASP.NET (Ch 01)</title></head> 
<body> 
<form runat="server"> 
    <Person id="dinoe" runat="server" /> 
    Click the <b>View|Source</b> menu item... 
</form> 
</body> 
</html>

  Тэг <Person> обрабатывается так, словно это обычный HTMLтэг, и при выполнении сценария к нему добавляется атрибут FavoriteFood. Каким получается результирующий HTMLкод страницы, показано на рис. 14. В приведенном примере типом объекта dinoe является HtmlGenericControl.

Рис. 1-4. ASP.NET обрабатывает пользовательские тэги, для которых не указано пространство имен, ставя их в соответствие классу HtmlGenericControl

  Однако  если тэг содержит информацию о пространстве имен, он принимается лишь при условии, что этим пространством является <asp:> либо пространство, явно ассоциированное с именем тэга посредством директивы @Register. Когда явно заданное пространство имен системе неизвестно, генерируется ошибка компиляции.

Серверные элементы управления ASP.NET

Все серверные  элементы управления ASP.NET делятся на два семейства: элементы управления HTML и элементы управления Web. Элементы, относящиеся к первому семейству, определены в пространстве имен System.Web.UI.HtmlControls, а относящиеся ко второму — в пространстве имен System.Web.UI.WebControls.

Серверные элементы управления HTML

Серверные элементы управления HTML — это классы, представляющие стандартные HTMLтэги, поддерживаемые большинством браузеров. Набор свойств такого элемента управления соответствует набору атрибутов представляемого им тэга. У серверного элемента управления HTML имеются простые свойства (InnerText, InnerHtml, Style и Value) и свойстваколлекции (Attributes). Экземпляр серверного элемента управления автоматически создается исполняющей средой ASP.NET, когда она встречает в обрабатываемом исходном файле страницы тэг, помеченный атрибутом runat="server".

  Как уже  упоминалось, набор серверных элементов  управления не охватывает всего набора HTMLтэгов каждой конкретной версии схемы HTML. В пространстве имен System.Web.UI.HtmlControls представлены лишь наиболее часто используемые тэги, а такие тэги, как <iframe>, <frameset>, <body>, <hn>, <fieldset>, <marquee> и <pre>, не имеют специализированных серверных представлений.

  Однако  то обстоятельство, что набор специальных  серверных элементов управления неполон, не ограничивает ваших программистских  возможностей, когда речь идет об использовании  и конфигурировании тэгов на сервере. Вам нужно лишь использовать более  универсальный интерфейс программирования — класс HtmlGenericControl, о котором уже упоминалось в этом разделе.

Серверные элементы управления Web

Серверные элементы управления Web обладают более широкими возможностями, чем серверные элементы управления HTML. К их числу относятся не только текстовые поля и кнопки, но и такие специализированные элементы, как календарь, баннер со сменяющейся рекламой, раскрывающийся список, древовидное представление данных и таблица данных. Кроме того, среди Webэлементов есть компоненты, очень похожие на некоторые серверные элементы управления HTML. ОднакоWebэлементы более абстрактны, чем соответствующие им HTMLэлементы, поскольку их объектная модель не обязательно должна соответствовать синтаксису HTML. Для примера можно сравнить серверный текстовый элемент управления HTML с серверным Webэлементом TextBox. HTMLэлемент имеет следующую разметку:

<input runat="server" id="FirstName" type="text" value="Dino" />

  А разметка Webэлемента TextBox такова:

<asp:textbox runat="server" id="FirstName" text="Dino" />

  Оба элемента управления генерируют одинаковый код  разметки, отправляемой браузеру. Однако программный интерфейс серверного текстового элемента HTML максимально приближен к интерфейсу HTMLтэга <input>, тогда как методы и свойства Webэлемента TextBox имеют более абстрактные имена. Так, для задания контента серверного текстового элемента HTML используется свойство Value, соответствующее одноименному атрибуту HTML, тогда как у элемента управления TextBox для той же цели применяется свойство Text. За некоторыми исключениями (о них я расскажу в главе 3) выбор между серверными элементами управления типа Web и HTML зависит от ваших предпочтений, а также от того, как вам удобнее разрабатывать и сопровождать страницы.

Стек  разработки ASP.NET

Если говорить на самом высоком уровне абстракции, разработка любого приложения ASP.NET осуществляется в два этапа: создание страниц  и конфигурирование среды их выполнения. Сначала вы создаете страницы приложения, реализуете требования пользователей, а затем настраиваете окружение, в котором оно будет функционировать, чтобы предоставление страниц осуществлялось максимально эффективным и безопасным способом. Как видно из рис. 1-2, компонентная модель ASP.NET является основой всех приложений ASP.NET и их строительных блоков. Руководствуясь этим рисунком, мы проанализируем разные логические уровни, чтобы разобраться, что и для чего они содержат.

Уровень представления

Страница ASP.NET состоит  из элементов управления, текста и  разметки. Когда ее исходный код  преобразуется в функционирующий  экземпляр класса страницы, исполняющая  среда ASP.NET перестает различать эти  три составляющие — для нее все они являются элементами управления, в том числе литеральный текст и символы возврата каретки. Во время выполнения страница ASP.NET является просто иерархией элементов управления.

Элементы  управления с богатым  интерфейсом

Богатство интерфейсов  программирования ASP.NET обеспечивается наличием большой библиотеки серверных  элементов управления, выполняющих  базовые задачи HTMLвзаимодействия — от простейших, таких как ввод текста с использованием стандартных тэгов, до довольно сложных, скажем, отображения данных в виде таблицы. Встроенный набор элементов управления настолько обширен, что удовлетворяет любым требованиям. Кроме того, в последней версии ASP.NET появились новые элементы управления с богатым интерфейсом (rich controls), называемые также элементами richтипа, которые позволяют существенно повысить производительность труда разработчиков страниц.

  В ASP.NET 2.0 вы найдете элементы управления для создания Webмастеров и представлений иерархических данных со свертываемыми ветвями, типичные формы, элементы для декларативного связывания данных, меню, средства навигации по сайту. Есть здесь даже миниAPI для создания сайтов портального типа. Применение элементов управления richтипа позволяет сократить время разработки и уменьшить количество ошибок, без усилий внедрить передовой опыт сообщества разработчиков и предоставить более гибкие и эффективные средства работы конечному пользователю. О таких элементах управления мы детально поговорим в главах 4, 6 и 10.

Специализированные  элементы управления

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

  Функции существующих элементов управления можно расширять. Можно также  создавать новые элементы управления путем объединения нескольких существующих элементов — такие составные элементы управления называютсяпользовательскими (user). Кроме того, в ASP.NET 1.x определен небольшой набор базовых классов, на основе которых можно создавать совершенно новые, так называемые специализированные (custom) элементы управления. В ASP.NET 2.0 этот набор классов расширен, в частности с целью упростить разработку новых элементов управления, связанных с данными.

Адаптивный  рендеринг

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

  Заметьте, однако, что новая адаптерная модель ASP.NET 2.0 не используется в мобильных элементах управления. Последние составляют особое семейство, разработанное специально для создания приложений, предназначенных для мобильных устройств. Такие элементы являются производными от MobileControl и размещаются на страницах, наследующих MobilePage. В мобильных элементах управления попрежнему используется старая адаптерная модель, разработанная специально для них и введенная еще в ASP.NET 1.1. Таким образом, в отношении создания приложений для мобильных устройств в ASP.NET 2.0 ничего не изменилось — для этой цели используются те же мобильные элементы управления, что и в ASP.NET 1.1.

  Так в  чем же суть новой адаптерной модели ASP.NET 2.0? Данная модель адаптивного рендеринга позволяет вам писать собственные адаптеры, настраивая серверные элементы управления для использования с определенными браузерами. Например, можно написать адаптер, генерирующий для элемента управления Calendar особую HTMLразметку, предназначенную для вывода конкретным целевым браузером.

Внутренняя  организация страницы и процесс ее выполнения

Любая страница ASP.NET является экземпляром класса, наследующего класс Page. Класс страницы — это конечная точка конвейера модулей, через который проходит запрос HTTP в процессе его обработки. Различные системные компоненты, работающие над исходным запросом, шаг за шагом формируют информацию, необходимую для поиска объекта страницы, который сгенерирует результирующую разметку, предназначенную для отправки браузеру. Объектная модель страницы поддерживает ряд функций и возможностей, каждая из которых относится к одной из следующих базовых категорий: события, сценарии, персонализация, стилевое оформление, прототипы.

События страницы

Жизненный цикл страницы в исполняющей среде ASP.NET отмечен серией событий. Путем написания кода обработки этих событий разработчики могут динамически модифицировать вывод страницы и состояние составляющих ее элементов управления. В ASP.NET 1.x страница генерирует такие события, как Init, Load, PreRender и Unload, соответствующие ключевым моментам ее жизненного цикла. В ASP.NET 2.0 добавлен ряд новых событий, позволяющих точнее отслеживать процесс обработки запроса. В частности, введены новые события, сигнализирующие о начале и окончании фаз инициализации и загрузки страницы. Жизненный цикл страницы ASP.NET мы детально проанализируем в главе 3.

Сценарии  страницы

Объектная модель сценариев страницы позволяет разработчику управлять кодом сценариев и  скрытыми полями, вставляемыми в клиентские страницы. Эта объектная модель генерирует код на языке JavaScript, с помощью которого связываются между собой HTMLэлементы, генерируемые серверными элементами управления. Таким способом программируются функции, которые на сервере иначе реализовать невозможно. Например, используя данный подход, вы можете запрограммировать страницу таким образом, чтобы при ее отображении в браузере фокус ввода получил заданный вами элемент.

  Страницы ASP.NET имеют такую архитектуру, при  которой они способны вызывать серверные  методы без осуществления полного  возврата формы и последующего обновления всей страницы. Данный механизм удаленного вызова сценариев реализован на основе механизма обратного вызова, и  такое решение дает разработчикам  определенные преимущества. Применением  метода обратного вызова сценария (script callback) обеспечивается прямая передача функцииJavaScript результатов выполнения серверного метода, и эта функция может затем обновить пользовательский интерфейс страницы, используя динамический HTML. При таком способе работы передача данных серверу и обратно все равно происходит, но полного обновления страницы удается избежать.

  Обратный  вызов сценария — не единственная из числа давно ожидаемых сообществом разработчиков новых технологий ASP.NET 2.0. Еще одной такой технологией является межстраничный постинг (crosspage posting), позволяющий передать контент формы другой странице. Не обучаем ли мы нового пса старым трюкам^*? Может быть. Как упоминалось в этой главе, одной из наиболее важных особенностей ASP.NET является то, что каждая страница содержит только один тэг<form>, который осуществляет возврат формы той же самой странице. Это решение заложено в архитектуре ASP.NET, и оно имеет свои достоинства.

  В предыдущих версиях ASP.NET межстраничный постинг можно было реализовать тем же способом, что и в классической ASP, — с использованием тэга <form>, не помеченного атрибутом runat, то есть тэга <form> чистого HTML. Данный метод работает прекрасно, но он не вписывается в объектноориентированный и строго типизированный мир ASP.NET. Поэтому в ASP.NET 2.0 реализован новый, более современный метод межстраничного постинга.

Персонализация страницы

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

Стилевое  оформление страницы

Подобно темам Microsoft Windows XP, тема ASP.NET представляет собой комплекс настраиваемых стилей и визуальных атрибутов элементов сайта. Сюда относятся свойства элементов управления, таблицы стилей страницы, изображения и шаблоны страниц. Таким образом, тему можно считать чемто вроде суперCSS (CSS, Cascading Style Sheet — каскадная таблица стилей). Она идентифицируется именем и состоит из CSSфайлов, изображений и обложек элементов управления.Обложка (skin) элемента управления — это текстовый файл, который содержит используемое по умолчанию объявление данного элемента со значениями его свойств. Если, к примеру, разработчик размещает на странице элемент управленияDataGrid и не задает его визуальные свойства, при рендеринге этого элемента используются значения свойств, заданные в файле темы.

  Использование тем — замечательное решение, позволяющее одним махом изменять внешний вид и поведение страниц и, что более важно, делать их единообразными.

Прототипы страниц

Страницы практически  любого современного сайта имеют  единообразную структуру и однотипное оформление. На одних сайтах общими элементами структуры страниц являются только заголовок и нижний колонтитул, на других же могут использоваться сложные навигационные меню и  разнообразные элементы управления, в которые заключен контент сайта. В ASP.NET 1.x разработчикам рекомендуется заключать такие блоки пользовательского интерфейса в пользовательские элементы управления и использовать эти элементы в составе страниц. Однако очевидно, что такая модель подходит лишь для сайтов небольшого размера; если же сайт содержит сотни страниц, то управлять им будет слишком сложно.

  Для сайтов с богатым контентом подход, основанный на применении пользовательских элементов управления, не всегда приемлем, так как сопряжен с рядом проблем. Вопервых, ссылаясь на пользовательские элементы управления, необходимо дублировать код страниц. Вовторых, для того чтобы применить новый шаблон, разработчику приходится возиться с каждой страницей. А втретьих, HTMLэлементы, которые покрывают всю область контента, часто оказываются разделенными между несколькими пользовательскими элементами управления.

  В ASP.NET 2.0 задача создания прототипов страниц была решена путем введения концепции эталонной страницы (master page). Разработчики сайтов с большим количеством страниц, имеющих единообразную схему и однотипную функциональность, могут теперь программировать все это в одном эталонном файле, вместо того чтобы добавлять информацию об общей структуре в каждую страницу и при этом распределять соответствующую разметку между несколькими пользовательскими элементами управления. Основываясь на единой эталонной странице, разработчики могут создавать любое количество единообразных страниц контента, просто ссылаясь в них на эталонную страницу с помощью специального атрибута. Об эталонных страницах я расскажу в главе 6.

Исполняющая среда HTTP

Процесс, в результате которого в ответ на Webзапрос генерируется текст для браузера на чистом HTML, в ASP.NET 2.0 не особенно отличается от аналогичного процесса в ASP.NET 1.1. IIS принимает запрос, присваивает ему идентификационный токен и передает этот запрос ISAPIрасширению ASP.NET (aspnet_isapi.dll) — точке входа процедуры обработки запроса, осуществляемой ASP.NET. Это общая схема, а ее детали зависят от версии IIS и используемой модели процесса.

  Моделью процесса называется последовательность операций, осуществляемых с целью обработки запроса. Когда исполняющая среда ASP.NET функционирует поверх IIS 5.x, в основе модели процесса лежит отдельный рабочий процесс с именем aspnet_wp.exe. Этот процесс Microsoft Win32 получает управление непосредственно от IIS через ISAPIрасширение ASP.NET. Данному расширению передаются все запросы на получение ресурсов ASP.NET, и оно, в свою очередь, передает их рабочему процессу. Рабочий процесс загружает общеязыковую среду (Common Language Runtime, CLR) и запускает конвейер управляемых объектов, которые преобразуют исходный запрос в полнофункциональную страницу, предназначенную для отправки браузеру. Модуль aspnet_isapi и рабочий процесс реализуют такие системные функции, как повторное использование процессов (process recycling), кэширование выводимых страниц, мониторинг использования памяти и пулинг потоков. Каждое Webприложение выполняется в отдельном домене приложения (AppDomain), поддерживаемом рабочим процессом. По умолчанию рабочий процесс выполняется от имени учетной записи ASPNET, имеющей очень ограниченные разрешения.            

  Примечание Домен приложения, он же AppDomain, — это специфическая сущность общеязыковой среды .NET. AppDomain обеспечивает изоляцию управляемого кода во время его выполнения, соблюдение для него ограничений защиты и его выгрузку. Домен приложения является своего рода легковесным процессом, в который загружается несколько сборок (для надежного выполнения кода). В рамках одного процесса ЦПУ может выполняться несколько доменов приложений. Также не существует соответствия один-к-одному между доменами приложения и потоками. Одному домену приложения может принадлежать несколько потоков, и хотя каждый конкретный поток не связан с каким-то одним доменом приложения, в каждый конкретный момент он выполняется в одном домене.

  Когда ASP.NET функционирует под управлением IIS 6.0, по умолчанию используется иная модель процесса, в которой место aspnet_wp.exe занимает стандартный рабочий процесс IIS 6.0 (w3wp.exe). Он анализирует URL запроса и загружает необходимое расширение ISAPI. В частности, для запросов, связанных с ASP.NET, рабочий процесс загружает aspnet_isapi.dll. В модели процесса IIS 6.0 расширение aspnet_isapi отвечает за загрузку общеязыковой среды и запуск конвейера HTTP.

  Поступив  в HTTPконвейер ASP.NET, запрос проходит через ряд системных и определенных пользователем компонентов, осуществляющих его последовательную обработку. Целью выполнения этого процесса является нахождение класса страницы, способного сформировать ответ на запрос, и создание экземпляра данного класса. Разработчик приложения может до некоторой степени модифицировать исполняющую среду: изменить список установленных модулей HTTP, внести изменения в конфигурационные файлы, определить провайдеры состояния и персонализации, а также другие прикладные сервисы.

Системные модули HTTP

Модули HTTP — это ASP.NETаналоги фильтров ISAPI. Каждый такой модуль представляет собой класс .NET Framework, реализующий определенный интерфейс. Всеми приложениями ASP.NET наследуется ряд системных модулей HTTP, указанных в файле machine.config. Предустановленные модули реализуют такие функции, как аутентификация и авторизация, а также сервисы, связанные с состоянием сеанса. Модуль HTTP может выполнять предобработку и постобработку запроса, перехватывать и обрабатывать системные события, а также события, генерируемые другими модулями.

  Вы можете писать и регистрировать собственные  модули HTTP, интегрируя их в исполняющий конвейер ASP.NET, обрабатывать системные события и генерировать собственные. Кроме того, у вас есть возможность редактировать для каждого приложения в отдельности список используемых по умолчанию модулей HTTP. Сюда можно добавлять пользовательские модули и удалять те, которые вам не требуются.

Конфигурация  приложения

Поведение приложения ASP.NET регулируется множеством параметров, одни из которых задаются на уровне системы, другие зависят от характеристик  конкретного приложения. Единый набор системных параметров определяется в файлеmachine.config. Этот файл содержит используемые по умолчанию и специфические для компьютера значения всех поддерживаемых установок. Машинные установки обычно контролируются системным администратором, и приложениям не предоставляется право доступа к файлу machine.config для записи. Файл machine.config хранится вне Webпространства приложений и недоступен даже в том случае, когда в результате успешной атаки в систему внедряется злонамеренный код.

  Большинство значений, хранящихся в файле machine.config, разрешается переопределять на уровне приложения, для чего нужно создать один или несколько файлов web.config, связанных с конкретным приложением. Главный из них, область действия которого распространяется на все приложение, помещается в корневую папку этого приложения. Он содержит подмножество установок из файла machine.config и соответствует той же самой XMLсхеме. Назначение файла web.config — переопределение некоторых установок из числа задаваемых по умолчанию. Однако имейте в виду, что не все установки из файла machine.config можно переопределять в дочерних конфигурационных файлах. В частности, информация о модели процесса ASP.NET может быть задана только на уровне компьютера, то есть в файле machine.config.

  Если приложение содержит дочерние каталоги, для каждого  из них можно создать свой файл web.config. Таким образом, конфигурационные файлы образуют иерархию, на вершине которой расположен файл machine.config, ниже — файлweb.config из корневой папки приложения, а далее — файлы machine.config из его вложенных папок. Установками, заданными ниже по иерархии, переопределяются установки, заданные выше. При этом с помощью специальных тэгов можно не только переопределять значения одноименных параметров, но и добавлять новые параметры или удалять существующие. Набор установок, воздействующих на конкретную страницу, определяется как сумма установок из файла верхнего уровня и изменений, вносимых на низших уровнях иерархии. Если в той или иной папке приложения конфигурационный файл отсутствует, для содержащихся в ней страниц применяются установки высших уровней.

Прикладные  сервисы

Примерами важных сервисов, которые предоставляются  приложениям исполняющей средой ASP.NET, могут служить сервисы аутентификации, управления состоянием и кэширования. В ASP.NET 2.0 их число увеличилось — появились сервисы администрирования, управления членством и ролями, сервисы персонализации (рис. 1-5).

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

  Возможность настраивать конфигурацию времени  выполнения посредством установок, задаваемых в файлах machine.config и web.config, придает вашему коду известную гибкость. Однако этот механизм не обеспечивает возможности полноценной настройки сервисов. Поэтому в ASP.NET 2.0 интегрирована новая программная модель, добавляющая в общую систему классов шаблоны для создания пользовательских сервисов. Первоначально эта модель — модель провайдеров — была разработана для использования в нескольких образцах приложений ASP.NET, так называемых Starter Kits. Она определяет общий API компонентов различного назначения, именуемых провайдерами тех или иных функций. Этот API позволяет разработчику управлять поведением провайдера и выбирать подходящую схему данных и хранилище информации.

Рис. 1-5. Более детальная схема стека разработки ASP.NET (стрелка указывает направление от пользовательского интерфейса к системным сервисам)            

  Внимание! Модель провайдеров является одним из ключевых архитектурных элементов ASP.NET, и поэтому для эффективной разработки приложений важно понимать базовые принципы, положенные в ее основу. Данная модель существовала в ASP.NET и раньше, но при создании ASP.NET 2.0 была формализована и полностью отделена от платформы и среды исполнения, так что теперь ее можно использовать в любом приложении .NET, а не только в ASP.NET.

Модель  провайдеров ASP.NET

В основу модели провайдеров ASP.NET положена известная  архитектурная концепция — модель, которую называют «стратегия». Под стратегией в данном случае понимается необходимая приложению функциональность (скажем, сортировка данных), которая может быть реализована с использованием различных алгоритмов (например, быстрой сортировки или сортировки слиянием). Каждое приложение выбирает алгоритм, который максимально соответствует его нуждам, и для управления им использует стандартный API, общий для всех алгоритмов, реализующих данную функциональность.

  Важной  особенностью модели «стратегия» является то, что она дает объекту или  целой подсистеме возможность открыть  свою внутреннюю организацию таким  образом, чтобы клиент мог отключить  используемую по умолчанию реализацию той или иной функции и подключить другую ее реализацию, в том числе  собственную. Концепция стратегии  реализована также в модели провайдеров ASP.NET.

Для чего введена модель провайдеров

Для конечного  пользователя приложения применение модели провайдеров является абсолютно прозрачным; сам по себе этот факт не означает, что у приложения будет более богатый контент или что оно будет работать быстрее и гибче. Данная модель — это прежде всего элемент инфраструктуры, позволяющий разработчикам и архитекторам совершенствовать архитектуру приложения, внося определенные изменения на уровне системных компонентов. Кроме того, она дает разработчикам возможность создавать новые компоненты, параметры и поведение которых могут настраиваться клиентами. Реализация данной модели не превращает приложение в проект с открытым исходным кодом, в котором каждый может модифицировать все что угодно. Вы лишь открываете некоторые части приложения для настройки клиентами, делая это простым, элегантным и эффективным способом. Кроме того, реализация модели провайдеров в самой ASP.NET дает вам возможность настраивать определенные компоненты ее исполняющей среды. Для этой цели здесь определены специальные провайдерные классы, которые вы можете использовать в качестве базовых классов при создании собственных провайдеров.

Пример применения модели провайдеров

Как применяется  модель провайдеров и каковы ее основные преимущества, я продемонстрирую на примере схемы классической процедуры аутентификации пользователя, представленной на рис. 1-6. Последовательность блоков этой схемы соответствует потоку операций ASP.NET 1.1.

Рис. 1-6. Классическая схема проверки членства в приложениях ASP.NET 1.1

  Пользователю, пытающемуся подключиться к защищенной странице, предлагается ввести на странице входа свое имя и пароль. Введенные  данные передаются функции, которая  отвечает за подтверждение личности пользователя. ASP.NET 1.x может автоматически сверить их с учетными записями Windows или списком имен, содержащимся в файле web.config. Оба эти решения не очень хорошо подходят для реальных Webприложений, поэтому в большинстве случаев разработчикам приходится самостоятельно писать аутентификационный код, сверяющий введенные пользователем идентификационные значения с информацией из «доморощенного» источника данных. Схема и контейнер такого источника данных, как и алгоритм аутентификации, фиксированы и определяются разработчиком.

  Что плохого  в таком решении? Да, в общем, ничего. Оно нормально работает, дает программисту полный контроль над происходящим и  может быть адаптировано для других приложений. Единственный его недостаток — это отсутствие универсальной, раз и навсегда определенной модели аутентификации. Конечно, его можно переносить из одного приложения в другое, но более универсальное решение, построенное по модели провайдеров, портировать несравненно легче. Эти две схемы соотносятся между собой примерно так же, как метод вырезания и вставки соотносится с объектноориентированным наследованием.

  Рассмотрим  другой сценарий — управление состоянием сеанса. В ASP.NET 1.x состояние сеанса можно хранить в базе данных SQL Server или в памяти специального процесса, внешнего по отношению к приложению. В обоих случаях приходится придерживаться схемы данных, жестко закодированной в ASP.NET. Предположим, что вам больше подходит решение на основе базы данных, как более надежное, но в вашей системе не используется SQL Server. Тогда придется либо отказаться от идеи хранения состояния сеанса в базе данных, либо приобрести лицензию на SQL Server. Повлиять на поведение модуля ASP.NET, управляющего состоянием сеанса, вы никак не можете.

  Надеюсь, идея вам уже понятна: в ASP.NET есть модули, для использования которых  приходится соглашаться на определенную схему данных, определенное их хранилище  и определенное внутреннее поведение  модуля. Если чтолибо из предлагаемого вам не подходит, то ничего не остается, как отказаться от использования этих модулей и реализовать их функции самостоятельно (как в описанном выше примере с сервисом управления членством). В результате у вас получится собственная, специфическая для конкретного приложения система, автоматический перенос которой из одного приложения в другое будет невозможен. Кроме того, если вы наймете новых сотрудников, их придется обучать работе с этой системой. Наконец, вам придется приложить немало усилий, если вы захотите сделать свой API достаточно универсальным — таким, который можно расширять и повторно использовать в разных контекстах. (А иначе вы будете вынуждены снова и снова изобретать колесо.)

  Гораздо лучшим решением является применение модели провайдеров. В этом случае, вопервых, вы получаете хорошо документированные универсальные программные интерфейсы для выполнения типичных задач. А вовторых, у вас появляется возможность полностью контролировать внутреннее поведение и логику доступа к данным каждого API, реализованного согласно этой модели.

  Итак, в ASP.NET 1.1 у вас часто нет другого выхода, как писать собственный API для выполнения определенных функций желаемым способом. В ASP.NET 2.0 же поддерживается модель провайдеров, предлагающая лучшую альтернативу, так что грех ее не использовать.

  На рис. 1-7 приведена схема того же процесса, который был проиллюстрирован на рис. 1-6, но на этот раз реализованного по модели провайдеров. В ASP.NET 2.0 определен глобальный класс с именем Membership, содержащий группу статических методов. (Об API членства я подробно расскажу в главе 15.) Эти методы вызываются из приложения для выполнения различных операций, связанных с управлением членством, в том числе для проверки введенных пользователем имени и пароля, создания новых учетных записей пользователей и изменения паролей. Данный API расположен на верхнем уровне, а ниже вы можете подключать собственные провайдеры, которые выполняют указанные задачи тем способом, какой вам требуется. Написать новый провайдер очень просто — для этого достаточно создать класс, производный от известного базового класса, и переопределить в нем несколько методов. Провайдер, ответственный за выполнение конкретной задачи, задается в конфигурационном файле.

Рис. 1-7. Сервис членства, реализованный с помощью модели провайдеров в ASP.NET 2.0

Преимущества  модели провайдеров

Реализация в ASP.NET модели «стратегия» дает вам  два преимущества: возможность адаптации  среды выполнения приложения к собственным  нуждам и возможность повторного использования кода. Эта модель распространяется на несколько функциональных областей ASP.NET. Вы можете писать провайдеры для  управления членством пользователей, ролями, состоянием сеанса, для управления пользовательскими профилями с  применением технологии персонализации и для загрузки информации карты сайта из подходящих источников. Например, написав соответствующий провайдер, можно изменить схему данных, предназначенную для хранения идентификационной информации пользователей, с тем чтобы она содержалась, например, в базе данных Oracle или DB2, а пароли хранить хэшированными, а не в виде чистого текста. Столь беспрецедентно высокий уровень настройки системных компонентов открывает перед разработчиками множество новых возможностей. Вы можете писать совершенно новые провайдеры, а также расширять существующую модель новыми компонентами.

  Если посмотреть на ASP.NET 2.0 с точки зрения существующих приложений, модель провайдеров покажется еще более привлекательной, поскольку она является основой повторного использования кода и сохранения вложений в его разработку. Для создания реальных систем управления членством в ASP.NET 1.1 приходилось писать собственные API — об этом уже говорилось ранее. Как же следует поступить при переходе на ASP.NET 2.0? Отказаться от имеющихся наработок в пользу нового API членства или пользоваться собственным устаревшим API?

  Ни то, ни другое! Модель провайдеров открывает  перед вами уникальную возможность  интегрировать имеющийся код  в новую систему, построенную  по модели провайдеров, адаптировав  его таким образом, чтобы его  можно было подключить к новой системе стандартным способом. Для этой цели достаточно написать адаптер, то есть оболочку для старого кода, имеющую интерфейс провайдера. Концепция адаптера — это еще одна базовая концепция программных систем, суть которой заключается в том, что класс А снабжается интерфейсом Б, понятным клиентскому классу В.

  В нашем  случае это означает, что существующий код заключается в оболочку в виде нового провайдерного класса, бесшовно интегрирующегося в среду ASP.NET 2.0. Таким образом внутренняя реализация определенного сервиса, такого как сервис членства, меняется, а его API остается неизменным, равно как и код приложений, которые его используют. Тем самым достигается возможность повторного использования всего ранее написанного кода.

Реализация  модели провайдеров  в ASP.NET

Реализация модели провайдеров в ASP.NET состоит из трех элементов: класса провайдера, слоя конфигурации и слоя хранения. Класс провайдера — это компонент, который вы интегрируете в систему для получения требуемой функциональности. Конфигурационный слой предоставляет информацию, необходимую для идентификации нужного провайдера и создания его экземпляра. Слоем хранения является физическое хранилище данных. В зависимости от того, какой функциональностью должен обладать конкретный провайдер, этим хранилищем может быть Active Directory, таблица Oracle или SQL Server, XMLфайл или чтолибо еще.

Класс провайдера

Класс провайдера реализует известный его клиентам интерфейс, с помощью которого им предоставляется требуемая функциональность. Клиентам не обязательно знать детали реализации данного интерфейса. Такая прозрачность кода провайдера позволяет одному программному компоненту управлять другим, о коде которого он даже ничего не знает. Единственное отличие модели провайдеров ASP.NET от классической модели «стратегия» состоит в том, что вместо интерфейсов используются базовые классы.

  В ASP.NET не всякий класс, реализующий заданный интерфейс, может выступать в  роли класса провайдера. Он обязательно  должен быть производным от определенного  базового класса. Каждому из поддерживаемых ASP.NET типов провайдеров соответствует  свой базовый провайдерный класс. Этот класс определяет интерфейс провайдера в виде набора абстрактных методов. Все базовые провайдерные классы являются производными от одного общего классаProviderBase. У него имеется единственный переопределяемый метод, Initialize, через который исполняющая среда передает провайдеру необходимые установки из конфигурационных файлов. На рис. 1-8 представлена иерархия провайдерных классов для сервиса членства.

Рис. 1-8. Иерархия провайдерных классов

Интерфейсы  и базовые классы в сравнении

Пусть поднимут руки те разработчики, которые ни разу не участвовали в многочасовых дебатах  по поводу выбора между интерфейсами и базовыми классами. Такие дискуссии  по определению бесконечны, и ни один из двух противоположных лагерей  не желает сдавать свои позиции. Что  лучше использовать — интерфейсы или базовые классы? Какие соображения следует принять во внимание при поиске ответа на этот вопрос? Для начала давайте рассмотрим следующий факт.

  В выпусках ASP.NET 2.0, предшествующих версии Beta, была реализована модель провайдеров, в точности соответствующая модели «стратегия», то есть основанная на интерфейсах. В выпуске Beta 1 интерфейсы заменили базовыми классами, на которых в конце концов и решено было остановиться. Похоже, команда разработчиков самой ASP.NET нашла ответ на поставленный выше вопрос?

  Как известно, интерфейс представляет собой набор  логически связанных между собой  методов, содержащий только их объявления. Таким образом, интерфейсный тип — это частичное описание типа, которому потенциально может удовлетворять любое количество классов. Соответственно, хорошим интерфейсом можно считать такой интерфейс, который может быть реализован группой разных типов и инкапсулирует некую обобщенную полезную функциональность, необходимую клиентам. Вот почему имена многих интерфейсов оканчиваются на «able» (в переводе с англ. — способный): IDisposable, IComparable, IFormattable. Если интерфейс реализуется только одним классом, то, скорее всего, он неудачно спроектирован. Возможностью создания интерфейсов не следует злоупотреблять, чтобы не плодить ненужных типов; как правило, новые интерфейсы должны вводиться только после тщательного обдумывания.

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

Слой  конфигурации

Каждый поддерживаемый провайдерный тип ассоциируется с определенным разделом конфигурационных файлов, в котором задается используемый по умолчанию провайдер данной функциональности и перечисляются все доступные ее провайдеры. Если у провайдера имеются открытые свойства, посредством атрибутов раздела, в котором он определен, задаются значения этих свойств по умолчанию. Содержимое данного раздела передается в виде аргумента методу Initializeкласса ProviderBase — единственному общему для всех провайдеров методу. В нем каждый провайдер использует данную информацию для инициализации своего состояния. Приведем фрагмент кода конфигурационного раздела провайдерачленства:

<membership defaultProvider="AspNetSqlProvider"> 
    <providers> 
        <add name="AspNetSqlProvider" 
            type="System.Web.Security.SqlMembershipProvider, System.Web" 
            connectionStringName="LocalSqlServer" 
            enablePasswordRetrieval="false" 
            enablePasswordReset="true" 
            requiresQuestionAndAnswer="true" 
            ... 
            passwordFormat="Hashed" /> 
        ... 
    </providers> 
</membership>

Слой  хранения

Всем провайдерам  нужно записывать информацию в постоянную память и считывать ее оттуда. Во многих случаях два провайдера одного типа различаются только тем, где они хранят свои данные. Информация о хранилище содержится в атрибутах провайдера в разделе <providers>, как в приведенном выше фрагменте кода. Заданный в нем провайдер SqlProfileProvider — это предопределенный провайдер профилей, использующий для хранения своих данных таблицу SQL Server. Его строка подключения задается в атрибуте connectionStringName, который содержит ссылку на другой раздел конфигурационных файлов, предназначенный для централизованного хранения строк подключения.

  Для того чтобы провайдер мог выполнять  свою работу, ему необходима определенная инфраструктура (база данных, таблицы, отношения и т. п.). Соответствующее конфигурирование рабочего окружения обычно осуществляется на этапе развертывания. ASP.NET упрощает эту задачу, предлагая в помощь администратору специальную консоль управления сайтом (рис. 1-9).

Рис. 1-9. Консоль администрирования Web-сайта, вызываемая из Visual Studio .NET 2005

Существующие  типы провайдеров

Модель провайдеров  использована в ASP.NET для реализации целого ряда функций, среди которых  важнейшими являются следующие:

§ реализация механизма чтениязаписи для хранения информации пользовательских профилей;

§ создание определяемого пользователем репозитария учетных записей пользователей, поддерживающего наиболее типичные операции, как то: проверка существования заданного пользователя, добавление и удаление учетных записей пользователей, изменение паролей;

§ создание определяемого пользователем репозитария ролей пользователей;

§ определение карты сайта;

§ введение новых типов хранилищ данных состояния сеанса.

  Провайдерные классы, доступные в ASP.NET, перечислены в табл. 1-1.

Табл. 1-1. Базовые провайдерные классы ASP.NET

  В составе  каждого их этих классов определены абстрактные методы, соответствующие  различным аспектам функционирования провайдеров, доступным для настройки  пользователями. Например, у класса MembershipProvider имеются методы ValidateUser, CreateUser, DeleteUser, ChangePassword и т. д. Заметьте, что сам класс MembershipProvider в коде приложений никогда не используется, поскольку является абстрактным. Сказанное верно и в отношении других базовых провайдерных классов. Вместо них используются производные классы, такие как SqlMembershipProvider или, скажем, ActiveDirectoryMembershipProvider.

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

  Примечание Архитектура провайдеров, будучи одним из самых важных нововведений ASP.NET 2.0, является также и одним из наиболее сложных ее функциональных элементов, требующим грамотного использования. Чтобы разработчики допускали меньше ошибок, команда ASP.NET предлагает большое количество демонстрационного кода и набор провайдеров, показывающий, что можно и чего нельзя делать с их помощью. Написать пользовательский провайдер с нуля непросто по нескольким причинам. Во-первых, провайдеры должны поддерживать многопоточность, во-вторых, следует предпринять специальные меры, чтобы на этапе инициализации провайдера не мог произойти повторный вход. Поэтому, прежде чем начинать свой первый проект по разработке провайдера, обязательно ознакомьтесь с материалами, представленными в разделе Provider Toolkit в ASP.NET Developer Center на сайте Microsoft.

Заключение

Будучи частью .NET Framework, ASP.NET позволяет использовать все преимущества ее общеязыковой среды (CLR), такие как строгая типизация, наследование, взаимодействие кода, написанного на разных языках, и версионность. А поскольку ASP.NET — новейшая платформа Webприложений, в ней использовано все лучшее из других платформ, включая классическую ASP, JSP и LAMP. В ASP.NET реализована программная модель, которая, хотя и построена поверх протоколаHTTP, не сохраняющего состояние, обеспечивает сохранение состояния и позволяет создавать приложения, управляемые событиями.

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

Только  факты

§ Разрабатывая приложения для ASP.NET, вы можете использовать все преимущества общеязыковой среды .NET, такие как строгая типизация, наследование, надежная защита кода, а также взаимодействие кода, написанного на разных языках.

§ Страница ASP.NET во время выполнения представлена экземпляром класса, производного от класса Page.

§ Класс Page является конечной точкой конвейера модулей, обрабатывающих полученный сервером HTTPзапрос.

§ Только к тем элементам исходной страницы ASP.NET, которые помечены атрибутом runat, возможен программный доступ во время выполнения страницы на сервере.

§ Элементы страницы, не имеющие атрибута runat, не обрабатываются на сервере и выводятся как есть.

§ Атрибут runat применим практически ко всем тэгам, которые можно использовать в составе страницы ASP.NET, включая пользовательские и неизвестные тэги.

§ Моделью процесса называется последовательность операций, выполняемых для обработки запроса. Эта модель определяется IIS и, в свою очередь, определяет, в каком рабочем процессе и от имени какой учетной записи будут выполняться приложения ASP.NET.

§ Приложения ASP.NET работают от имени учетной записи с очень ограниченными разрешениями.

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

§ Модель провайдеров ASP.NET является инфраструктурным элементом, благодаря которому архитектура приложений стала более эффективной, а разработчики и архитекторы получили возможность действовать на уровне системных компонентов.

§ Модель провайдеров ASP.NET обладает двумя важными достоинствами: она позволяет настраивать и адаптировать исполняющую среду и обеспечивает возможность повторного использования кода.