• Главная
• Контакты
• Нашёл ошибку
• Прислать материал
• Добавить в избранное

До сих пор все примеры приложений в этой книге касались консольных приложений и приложений Windows Forms. В этой главе и далее мы выясним, каким образом платформа .NET упрощает задачу построения приложений о интерфейсом на основе браузера, Но сначала мы обсудим ряд ключевых для Web понятий (таких, как HTTP, HTML, сценарий клиента и сервера), а также роль Web-сервера (включая сервер разработки ASP.NET, WebDev.Webserver.exe),

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

Web-приложения очень сильно отличаются от традиционных приложений для настольных систем. Первым очевидным отличием является то, что любое реальное Web-приложение предполагает использование, как минимум, двух соединенных в сеть, машин (конечно, при разработке приложения вполне возможно, чтобы роли клиента и сервера играла одна машина). Задействованные машины должны согласовать использование определенного сетевого протокола для успешного осуществления отправки и приёма данных. Сетевым протоколом, соединяющим компьютеры в рассматриваемом нами случае, является протокол HTTP (Hypertext Transfer Protocol – протокол передачи гипертекста).

Когда машина-клиент запускает Web-браузер (такой, как Netscape Navigator, Mozilla Firefox или Microsoft Internet Explorer), генерируется HTTP-запрос доступа к конкретному ресурсу (например, к файлу *.aspx или *.htm) на удаленной машине-сервере. Протокол HTTP – это текстовый протокол, построенный на стандартной парадигме запросов и ответов. Например, при обращении к http://www.IntertechTraining.com программное обеспечение браузера использует Web-технологию, называемую сервисом DNS (Domain Name Service – служба имен доменов), которая позволяет превратить зарегистрированный адрес URL в 4-байтовое (32-разрядное) числовое значение (называемое IP-адресом). После этого браузер открывает сокет (обычно через порт с номером 80) и посылает HTTP-запрос странице, используемой Web-узлом http://www.IntertechTraining.com по умолчанию. Осуществляющий хостинг Web-сервер получает поступающий HTTP-запрос, и указанный в запросе ресурс может содержать программную логику, способную прочитать значения, введенные клиентом (например, в окне текстового блока), чтобы сформировать HTTP-ответ, Разработчик Web-программы может использовать любые технологии (CGI, ASP, ASP.NET, сервлеты Java и т.д.), чтобы динамически генерировать содержимое HTTP-ответа. Затем браузер клиента отображает HTML-код, полученный от Web-сервера. На рис. 23.1 показана общая схема цикла запросов-ответов HTTP.

Рис. 23.1. Цикл запросов и ответов HTTP

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

Под Web-приложением можно понимать коллекцию файлов (*.htm, *.asp, '*.aspx, файлы изображений и т.д.) и связанных компонентов (например, таких как библиотека программного кода .NET), хранимых в отдельном семействе каталогов на данном Web-сервере. Как будет показано в главе 24, Web-приложения имеют специфический цикл существования и поддерживают множество специальных событий (например, события начальной загрузки и окончательного завершения работы), которые вы можете обработать.

Web-сервер - это программный продукт, обеспечивающий хостинг для ваших Web-приложений, и, как правило, предлагающий целый ряд сопутствующих сервисов, таких как, например, интегрированные службы безопасности, поддержка FTP (File Transfer Protocol – протокол передачи файлов), службы обмена почтовыми сообщениями и т.д. Web-сервером производственного уровня является сервер IIS (Internet Information Server – информационный сервер Интернет) от Microsoft, который, как вы можете догадаться, предлагает внутреннюю поддержку и "классических" Web-приложений ASP, и Web-приложений ASP.NET.

При создании Web-приложений ASP.NET вам потребуется взаимодействие с IIS. И здесь важно подчеркнуть, что сервер IIS по умолчанию при установке Windows Server 2003 или Windows XP Professional Edition не устанавливается (а среда Windows XP Home Edition поддержку IIS не предлагает вообще). Поэтому, в зависимости от конфигурации вашей машины разработки, вам, возможно, придется установить IIS вручную. Для этого откройте окно Установка и удаление программ (Add/Remove Program) из папки Панель управления (Control Panel) и выберите в нем Установка компонентов Windows (Add/Remove Windows Components).

Замечание. Сервер IIS лучше установить до установки .NET Framework. Если установить IIS после установки .NET Framework, то Web-приложения ASP.NET не будут выполняться корректно (вы увидите только пустые страницы). К счастью, можно настроить IIS на поддержку .NET-приложе-ний с помощью запуска утилиты командной строки aspnet_regiis.exe (с флагом /i).

В предположении о том, что на вашей рабочей станции сервер IIS установлен должным образом, вы сможете взаимодействовать с IIS из папки Администрирование (размещенной в папке Панель управления). Для работы с материалом этой шалы нас будет интересовать только узел Web-узел по умолчанию (Default Web Site), рис. 23.1.

Рис. 23.2. Окно оснастки IIS

Одна инсталляция IIS способна обслуживать множество Web-приложений, каждое из которых размещается в своем виртуальном каталоге. Каждый виртуальный каталог проецируется в физический каталог на локальном жестком диске. Так, если вы создадите новый виртуальный каталог с именем CarsRUs, внешние пользователи смогут просматривать этот узел, используя, например, адрес URL http://www.CarsRUs.com (в предположении о том, что IР-адрес вашего узла имеет всемирную регистрацию). В фоновом режиме виртуальный каталог отображается в соответствующий физический корневой каталог, например, в C:\inetpub\www-root\AspNetCarsSite, в котором находится содержимое Web-приложения.

При создании Web-приложения ASP.NET с помощью Visual Studio 2005 вы имеете возможность генерировать новый виртуальный каталог для текущего Web-узла. Вы также можете создать виртуальный каталог вручную. Для примера предположим, что нам нужно создать простое Web-приложение с именем Cars. Первым шагом при этом оказывается создание на машине новой папки (например, папки C:\CodeTests\CarsWebSite), которая будет содержать коллекцию файлов, компонующих новый узел.

Затем нужно создать новый виртуальный каталог для узла Cars. Просто щелкните в окне IIS правой кнопкой мыши в строке Веб-узел по умолчанию и выберите Создать>Виртуальный каталог из появившегося контекстного меню. Будет запущен интегрированный мастер создания виртуальных каталогов. Перейдите от окна приветствия к следующему окну и укажите для вашего Web-узла подходящий псевдоним (Cars). Далее вас попросят указать физическую папку на жестком диске, которая содержит файлы и изображения, используемые для этого узла (для нашего примера это папка C:\CodeTests\CarsWebSite).

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

Рис. 23.3. Виртуальный каталог Cars

Комплект поставки ASP.NET 2.0 содержит "облегченную" версию Web-сервера под названием WebDev.WebServer.exe. Эта утилита позволяет разработчику осуществлять хостинг Web-приложений ASP.NET 2.0 за границами IIS. С помощью этого инструмента вы можете строить и проверять Web-страницы из любого каталога на своей машине (что очень удобно при разработке сценариев в группе разработчиков и при создании Web-программ ASP.NET 2.0 в среде ОС Windows XP Home Edition, которая не поддерживает US).

Замечание. Сервер WebDev.WebServer.exe нельзя использовать для тестирования "классических" Web-приложений ASP.

При построении Web-узла с помощью Visual Studio 2005 вы имеете возможность использовать WebDev.WebServer.exe для обслуживания создаваемых страниц. Но вы также имеете возможность взаимодействовать с этим инструментом вручную из командной строки .NET. Если ввести команду

WebDev.WebServer.exe -?

вы увидите окно сообщения, в котором будут описаны действительные опции командной строки. В сущности, вам нужно указать неиспользуемый порт с помощью опции /port:, корневой каталог Web-приложения с помощью опции /path: и необязательный виртуальный путь с помощью опции /vpath: (если вы не укажете значение /vpath:, по умолчанию используется значение /). Рассмотрим следующий пример.

WebDev.WebServer.exe /port: 12345 /path:"C:\CodeTests\CarsWebSite"

После ввода этой команды вы можете запустить свой любимый Web-браузер для запроса соответствующих страниц. Так, если в папке CarsWebSite содержится файл с именем MyPage.aspx, вы можете ввести следующий адрес URL.

http://localhost:12345/CarsWebSite/MyPage.aspx

Во многих примерах из этой и следующей глав WebDev.WebServer.exe будет использоваться через Visual Studio 2005. Следует учитывать то, что этот Web-сервер не предназначен для хостинга Web-приложений производственного уровня, он предназначен исключительно для целей разработки и тестирования.

Замечание. Проект Mono (см. главу 1) предлагает бесплатное расширение ASP.NET для Web-сервера Apache. За более подробной информацией обратитесь по адресу: http://www.mono-project.com/ASP.NET

Сконфигурировав каталог для своего Web-приложения, вы должны создать и его содержимое. Напомним, что Web-приложение - это просто термин используемый для обозначения множества файлов, обеспечивающих функционирование узла, Значительная часть этих файлов будет содержать синтаксические лексемы, определенные в рамках HTML (Hypertext Markup Language – язык гипертекстовой разметки). HTML – это стандартный язык, используемый для описания того, как в окне браузера клиента должна выполняться визуализация буквального текста, изображений, внешних ссылок и различных элементов графическом) интерфейса.

Этот специальный аспект Web-разработки является одной из главных причин столь распространенной нелюбви программистов, которую они испытывают к разработке Web-программ. И хотя современные средства Web-разработки (включан Visual Studio 2005) и платформы (такие как ASP.NET) генерируют большинство HTML-кода автоматически, сегодня для успешной работы с ASP.NET все еще важно хорошо понимать этот язык. Данный раздел, конечно же, ни в коей мере не претендует на охват всех аспектов HTML, но давайте рассмотрим основные.

Файл HTML состоит из множества дескрипторов, описывающих представление данной Web-страницы. Как и следует ожидать, базовая структура любого HTML-документа примерно одинакова. Например, файлы *.htm (или, альтернативно, файлы *.html) открываются и закрываются дескрипторами ‹html› и ‹/html›, обычно в них определяется раздел ‹body› и т.д. Следует иметь в виду, что HTML не чувствителен к регистру символов. Поэтому для браузера ‹HTML›, ‹html› и ‹Html› оказываются идентичными.

Для демонстрации некоторых базовых возможностей HTML откройте Visual Studio 2005, создайте пустой HTML-файл, выбрав File>New>File из меню, и сохраните этот файл под именем default.htm в каталоге C:\CodeTests\CarsWebSite. Наша исходная разметка весьма незамысловата.

‹html›

 ‹body›

 ‹/body›

‹/html›

Дескрипторы ‹html› и ‹/html› используются для обозначения начала и конца документа. Как вы можете догадаться, Web-браузер использует эти дескрипторы, чтобы выяснить, с какого места следует начать и где следует закончить обработку признаков форматирования, указанных в главной части документа. Почти все содержимое документа определяется в рамках дескриптора ‹body›. Чтобы немного "оживить" страницу, определите ее заголовок так, как показано ниже.

‹html›

 ‹head›

  ‹title›Web-страница Cars‹/title›

 ‹/head›

 ‹body›

 ‹/body›

‹/html›

Вы, наверное, догадались, что дескрипторы ‹title› используются для обозначения текстовой строки, которая при вызове этой страницы должна размещаться в строке заголовка окна Web-браузера.

Реальное действие в файле *.htm происходит в рамках элементов ‹form›. HTML-форма - это просто именованная группа связанных элементов пользовательского интерфейса, используемых для сбора данных пользовательского ввода, которые затем передаются Web-приложению по протоколу HTTP. He следует путать HTML-форму со всей областью окна браузера. Фактически HTML-форма представляет собой логическое объединение элементов, размещенных между дескрипторами ‹form› и ‹/form›.

‹html›

 ‹head›

  ‹titlе›Web-страница Cars‹/title›

 ‹/head›

 ‹body›

  ‹form id="defaultPage" name="defaultPage"›

   ‹!-- Место для Web-содержимого --›

  ‹/form›

 ‹/body›

‹/html›

Для id и name этой формы указано значение default Page. Как правило, открывающий дескриптор ‹form› задает также атрибут aсtion, указывающий адрес URL, по которому следует передать данные формы, и метод передали этих данных (POST или GET). Эти возможности дескриптора ‹form› мы рассмотрим чуть позже. Пока чего давайте выясним, какие элементы могут размещаться в HTML-форме. В панели инструментов Visual Studio 2005 предлагается специальный раздел HTML, в котором сгруппированы связанные с HTML элементы управления (рис. 23.4).

Рис. 23.4. Раздел HTML в окне панели инструментов

Перед добавлением HTML-элементов в HTML-форму важно заметить, что Visual Studio 2005 позволяет редактировать содержимое файлов *.htm с помощью интегрированного HTML-редактора и окна свойств. При выборе DOCUMENT в окне свойств (рис. 23.5) вы получаете возможность настройки ряда параметров HTML-страницы, например цвета ее фона.

Теперь измените раздел ‹body› файла default.htm так, чтобы отобразить пользователю приглашение ввести имя и пароль, и установите для фона тот цвет, который вам нравится (вы можете вводить и форматировать текстовое содержимое непосредственно в окне НТМL-редактора).

‹html›

 ‹head›

  ‹titlе›Web-страница Cars‹/title›

 ‹/head›

 ‹body bgcolor="NavajoWhite"›

  ‹!-- Приглашение ввода для пользователя --›

  ‹h1 align="center"›Страница входа в систему Cars‹/h1›

  ‹р align="center"›‹br›Введите ‹i›имя пользователя‹/i› и ‹i›пароль‹/i›.‹/р›

  ‹form id="defaultPage" name="defaultPage"› ‹/form›

 ‹/body›

‹/html›

Рис. 23.5. Редактирование HTML-документа средствами VS .NET

Теперь давайте построим саму HTML-форму. Вообще говоря, каждый HTML-элемент описывается с помощью атрибута name (соответствующее значение используется для программной идентификации элемента) и атрибута type (это значение задает вид элемента интерфейса, который вы хотите поместить в рамки декларации ‹form›). В зависимости оттого, с каким элементом интерфейса вы работаете, в окне свойств появляется дополнительные атрибуты, присущие данному конкретному элементу.

Пользовательский интерфейс, который мы собираемся здесь построить, будет содержать два текстовых поля ввода (одно из которых – типа Password) и два кнопочных типа (один для подачи запроса с данными формы, а другой – для сброса данных формы в значения по умолчанию).

‹!-- Построение формы для получения информации от пользователя --›

‹form name="defaultPage" id="defaultPage"›

 ‹P align="center"›Имя пользователя:

  ‹input id="txtUserName" type="text" NAME="txtUserName"›

 ‹/P›

 ‹P align="center"›пароль:

  ‹input name="txtPassword" type="password" ID="txtPassword"›

 ‹/P›

 ‹P align="center"›

  ‹input name="btnSubmit" type="submit" value="Отправить" io="btnSubmit"›

  ‹input name="btnReset" type="reset" value="C6poc" ID="btnReset"›

‹/form›

Обратите внимание на то, что здесь для каждого элемента назначены соответствующие значения name и id (txtUserName, txtPassword, btnSubmit и btnReset). Еще более важно то, что каждый элемент ввода имеет дополнительный атрибут type, который ясно идентифицирует их как вполне определенные элементы пользовательского интерфейса. Например, type="reset" указывает на автоматическую очистку всех полей формы и присвоение им начальных значений, type="password" – маскированный ввод пароля, a type="submit" – отправку данных формы получателю. На рис. 23.6 показан вид получившейся страницы.

Рис. 23.6. Исходный вид страницы, сохранённой в файле default.htm

Данный файл *.htm может содержать блок кода сценария, который будет помещен в ответный поток и обработан браузером, запросившим этот поток. Есть две главные причины, по которым используются сценарии клиента.

• Проверка пользовательского ввода перед отправкой данных Web-серверу.

• Взаимодействие с моделью DOМ целевого браузера.

В отношении первого пункта следует понимать, что "наследственной" проблемой Web-приложений является необходимость частых обращений к серверу (называемых вторичными обращениями) для обновления HTML-кода, отображаемого в окне браузера. И хотя вторичных обращений полностью избежать нельзя, всегда нужно стремиться минимизировать сетевой обмен. Одним из подходов, уменьшающих количество циклов сетевого обмена, является использование сценария клиента для проверка правильности пользовательского ввода перед отправкой данных формы Web-серверу. Если обнаруживается ошибка (например, не указаны данные в одном из обязательных полей), можно предложить пользователю исправить ошибку, не посылая данные Web-серверу напрасно. (В конце концов, ничто не раздражает пользователя больше, чем отправка данных по медленной связи только для того, чтобы получить в ответ совет исправить ошибки ввода!)

В дополнение к проверке пользовательского ввода, сценарии клиента могут также использоваться для взаимодействия с объектной моделью DOM (Document Object Model – объектная модель документов) браузера. Большинство коммерческих браузеров предлагает множество объектов, которые можно использовать для управления поведением браузера. Главным раздражающим фактором здесь является то, что различные браузеры предлагают подобные, но не идентичные объектные модели. Поэтому запущенный вами сценарий клиента, взаимодействующий с DOM, может работать по-разному в разных браузерах.

Замечание. ASP.NET поддерживает свойство HttpRequest.Browser, которое позволяет в среде выполнения определить возможности браузера, отправившего текущий запрос.

Имеется множество языков сценариев, которые могут использоваться для написания программного кода сценариев клиента. Двумя наиболее популярными из них являются VBScript и JavaScript. Язык VBScript представляет собой подмножество языка программирования Visual Basic 6.0. Следует подчеркнуть, что Microsoft Internet Explorer (IE) – это единственный Web-браузер, имеющий встроенную поддержку VBScript клиента. Поэтому если вы хотите, чтобы ваши HTML-страницы работали корректно в любом коммерческом Web-браузере, для программной логики сценариев клиента лучше VBScript не использовать.

Другим популярным языком сценариев является JavaScript. Здесь следует подчеркнуть, что JavaScript никоим образом не является подмножество языка Java. Хотя JavaScript и Java имеют несколько схожий синтаксис, JavaScript нельзя безоговорочно отнести к семейству языков ООП, поэтому этот язык оказывается далеко не таким мощным, как Java. Но здесь важно то, что все современные Web-браузеры поддерживают JavaScript, что делает этот язык естественным кандидатом на роль языка сценариев клиента.

Замечание. Чтобы еще больше усложнить ситуацию, напомним также о JScript.NET – управляемом языке программирования, с помощью которого, используя подобный сценариям синтаксис, можно строить компоновочные блоки .NET.

Чтобы продемонстрировать роль сценариев клиента, давайте выясним, как можно выполнить перехват событий, посылаемых HTML-элементами пользовательского интерфейса клиента. Предположим, что вы добавили в свою HTML-страницу default.htm тип Button (с именем btnHelp), которая должна предоставить пользователю возможность увидеть информацию справки. Чтобы выполнить перехват события Click для этой кнопки, активизируйте окно просмотра HTML и выберите имя кнопки из левого раскрывающегося списка. Затем в правом раскрывающемся списке выберите событие onclick. В результате этого в определение атрибута нового типа Button будет добавлен атрибут onclick.

‹input id="btnHelp" type="button" Value="Help" language="javascript" onclick="return btnHelp_onclick()"/›

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

‹script language="javascript" type="text/javascript"›

‹!--

function btnHelp_onclick() {

 alert("Это не так уж трудно. Просто щелкните на кнопке Отправить!");

}

-->

‹/script›

Обратите внимание на то, что блок сценария помещен в рамки HTML-комментария (‹!-- --›). Причина этого очень проста. Если ваша страница окажется в браузере, не поддерживающем JavaScript, программный код будет интерпретирован как комментарий и потому проигнорирован. Конечно, возможности вашей страницы будут более узкими, но зато ваша страница не будет полностью отвергнута браузером.

Теперь давайте добавим в нашу страницу default.htm клиентскую поддержку контроля вводимых в форму данных. Нам нужно, чтобы при щелчке пользователя на кнопке Отправить вызвалась функция JavaScript, которая проверяла бы каждый текстовый блок на пустые значения. При наличии пустого значения должно появиться окно сообщения с указанием ввести правильные данные. Сначала обработайте событие onclick для кнопки Отправить.

‹input name="btnSubmit" type="Submit" value="Submit" id="btnSubmit" languaege="javascript" onclick="return btnSubmit_onclick()"›

Этот обработчик события реализуйте так, как показано ниже.

function btnSubmit_onclick() {

 // Если пользователь о чем-то забыл, отобразить сообщение.

 if ((defaultPage.txtUserName.value == "") || (defaultPage.txtPassword.value == "")) {

  alert("Следует указать имя пользователя и пароль!");

  return false;

 }

 return true;

}

Теперь вы можете открыть свой любимый браузер, перейти к странице default.htm в виртуальном каталоге Cars и проверить работу вашего сценария клиента.

http://localhost/Cars/default.htm

Теперь, когда у вас есть простая HTML-страница, мы должны выяснить, как передать данные формы обратно Web-серверу для обработки. При построении HTML-формы в открывающем дескрипторе ‹form› обычно задается атрибут action, указывающий получателя вводимых в форму данных. Возможными получателями могут быть почтовые серверы, другие файлы HTML, файлы ASP (как "классические", так и .NET) и т.д. Для нашего примера мы используем "классический" файл ASP с именем ClassicAspPage.asp. Обновите свой файл default.htm, указав в нем следующие атрибуты в открывающем дескрипторе ‹form›.

‹form name="defaultPage" id="defaultPage" action="http://localhost/Cars/ClassicAspPage.asp" method = "GET"›

‹/form›

Добавленные атрибуты гарантируют, что при щелчке на кнопке Отправить данные формы будут отправлены файлу ClassicAspPage.asp с указанным URL. Указание method = "GET" для режима передачи означает, что данные формы присоединяются к строке запроса в виде набора пар имен и значений, разделенных символами амперсанда.

http://localhost/Cars/ClassicAspPage.asp?txtUserName=Andrew&txtPassword=abcd123$&btnSubmit=Submit

Другой метод передачи данных формы Web-серверу указывается с помощью method = "POST".

‹form name="defaultPage" id="defaultPage" action="http://localhost/Cars/ClassicAspPage.asp" method = "POST"›

‹/form›

В этом случае данные формы не присоединены к строке запроса, а записываются в отдельной строке в рамках HTTP-заголовка. При использовании POST данные формы будут невидимы для внешнего наблюдателя. Еще более важно то, что POST не имеет ограничений на длину символьных данных (многие браузеры выдвигают ограничения на длину запросов с использованием GET). Пока что для отправки данных формы странице-получателю *.asp мы будем использовать HTTP-метод GET.

"Классическая" ASP-страница является комбинацией HTML и программного кода сценария сервера. Если вы никогда не работали с ASP, вам будет полезно знать, что целью использования ASP является динамическое построение HTML-кода с помощью сценария сервера и небольшого набора классических COM-объектов. Например, вы можете иметь серверный блок VBScript (или JavaScript), который читает таблицу из некоторого источника данных, используя классическую технологию ADO, и возвращает строки в виде HTML-таблицы общего вида.

В нашем примере ASP-страница использует внутренний COM-объект Request, чтобы прочитать введенные в форму данные (присоединенные к строке запроса) и возвратить их обратно вызывающей стороне в виде эхо (не слишком впечатляет, но поставленная задача будет выполнена). Для сценария сервера мы используем VBScript (что обозначено директивой language).

С этой целью создайте новый HTML-файл и сохраните его с именем ClassicAspPage.asp в той папке, куда проецируется ваш виртуальный каталог (например, в папке C:\CodeTests\CarsWebSite). Реализуйте эту страницу так, как предлагается ниже.

‹%@ language="VBScript" %›

‹html›

 ‹head›

  ‹titlе›Страница Cars‹/title›

 </head>

 ‹body›

  ‹h1 align="center"›Вот что вы нам прислали:‹/h1›

  ‹P align="center"›‹b›Имя пользователя: ‹/b›

  ‹%= Request.QueryString("txtUserName") %›‹br›

  ‹b›Пароль: ‹/b›

  ‹%= Request.QueryString("txtPassword") %›‹br›

 ‹/body›

</html>

Здесь COM-объекта Request ASP используется для вызова метода QueryString() с целью анализа значений, содержащихся в HTML-элементах и переданных с помощью method = "GET". Обозначение ‹%=… %› является сокращением для требования "вставить указанное непосредственно в исходящий HTTP-ответ". Чтобы достичь большей гибкости, вы могли бы взаимодействовать с COM-объектом Response в рамках всего блока сценария (обозначаемого знаками ‹% %›). В этом здесь необходимости нет, однако вот простой пример.

‹%

 Dim pwd

 pwd = Request.QueryString("txtPassword")

 Response.Write(pwd)

%›

Очевидно, что объекты Request и Response классической схемы ASP предлагают целый ряд дополнительных членов, кроме показанных ниже. К тому же, в рамках классического подхода ASP определяется небольшой набор дополнительных COM-объектов (Session, Server, Application и т.д.), которые вы тоже можете использовать при построении Web-приложения.

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

Чтобы проверить программную логику ASP в нашем случае, просто загрузите страницу default.htm в браузер и введите в форму данные. После обработки соответствующего сценария на Web-сервере вы получите новый (динамически сгенерированный) HTML-код (рис. 23.7).

В настоящий момент для отправки данных формы целевому файлу *.asp в вашем файле default.htm указан HTTP-метод GET. При использовании этого подхода значения, содержащиеся в элементах управления графического интерфейса, присоединяются в конец строки запроса. Здесь важно подчеркнуть, что ASP-метод Request.QueryString() способен извлекать данные, переданные только с помощью метода GET.

Рис. 23.7. Динамически сгенерированная HTML-страница

Чтобы представить данные формы Web-pecypcy, используя HTTP-метод POST, можно использовать коллекцию Request.Form, чтобы прочитать значения на сервере, например:

‹body›

 ‹h1 align="center"›Bот что вы нам прислали:‹/h1›

 ‹Р align="center"›

 ‹b›Имя пользователя: ‹/b›

 ‹%= Request.Form("txtUserName") %› ‹br›

 ‹b›Пароль: ‹/b›

 ‹%= Request.Form("txtPassword") %› ‹br›

‹/body›

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

Исходный код. Файл примера ClassicAspPage размещен в подкаталоге, соответствующем главе 23.

С помощью классической технологии ASP (Active Server Pages – активные серверные страницы) создано очень много популярных Web-узлов, но эта архитектура имеет свои ограничения. Возможно, самым большим ограничением классической технологии ASP как раз и является то, что делает эту технологию такой мощной – это языки сценариев сервера. Языки сценариев, такие как VBScript и JavaScript, являются интерпретируемыми, не предусматривающими определения типов данных и не способствующими созданию надежных объектно-ориентированных программных конструкций.

Второй проблемой классической технологии ASP оказывается то, что программный код страницы *.asp не является строго модульным. Поскольку ASP представляет собой комбинацию HTML и сценариев в рамках одной страницы, большинство Web-приложений ASP оказывается "странной смесью" двух совсем разных подходов в программировании. И хотя классическая технология ASP позволяет разделить Многократна используемый программный код на отдельные включаемые в проект файлы, лежащая в основе такого разделения объектная модель не обеспечивает истинное разграничение обязанностей. В идеале каркас Web-разработки должен позволить программной логике представления (т.е. дескрипторам HTML) существовать независимо от программной логики реализации (т.е. программного кода, реализующего функциональные возможности приложения).

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

Уже первая главная реализация ASP.NET (версии 1.x) предложила фантастические возможности преодоления ограничений, присущих классической технологии ASP. По сути, платформа .NET дала начало использованию следующих подходов.

• ASP.NET 1.x предлагает модель, основанную на использовании внешнего кода поддержки и позволяющую отделить логику представления от логики реализации.

• Страницы ASP.NET 1.x представляют собой скомпилированные компоновочные блоки .NET, а не интерпретируемые строки языка сценариев, которые обрабатываются значительно медленнее.

• Web-элементы управления позволяют программисту строить Web-приложения с графическим интерфейсом приблизительно так же, как и приложения Windows Forms.

• Web-элементы ASP.NET автоматически обновляют своё состояние при вторичных запросах, для чего используется скрытое поле формы, имеющее имя __VIEWSTATE.

• Web-приложения ASP.NET являются полностью объектно-ориентированными и используют CTS (Common Type System – общая система типов).

• Web-приложения ASP.NET легко конфигурировать с помощью стандартных средств IIS или с помощью файла конфигурации Web-приложения (Web.config).

Технология ASP-NET 1.x была большим шагом в правильном направлении, но ASP.NET 2.0 обеспечивает дополнительные преимущества.

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

• В ASP.NET 2.0 для разрабатываемого и тестируемого Web-узла уже не требуется хостинг в IIS. Теперь вы можете разместить свой узел в любом каталоге на жестком диске.

• ASP.NET 2.0 поставляется с большим набором новых Web-элементов (элементы управления безопасностью, элементы управления данными, элементы пользовательского интерфейса и т.д.), дополняющим набор элементов управления ASP.NET 1.x.

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

• В ASP.NET 2.0 поддерживаются темы, которые предлагают декларативный метод изменения внешнего вида всего Web-приложения.

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

• В ASP.NET 2.0 поддерживается Web-утилита конфигурации и управления, которая осуществляет управление файлами Web.config.

Если бы здесь ставилась задача описать все новые возможности ASP.NET 2.0, эта книга была бы в два раза больше. Поскольку тема Web-разработки не является единственной темой рассмотрения, для получения более конкретной информации о том, что здесь не представлено, обратитесь к документации .NET Framework 2.0.

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

• Базовые функциональные возможности (типы, обеспечивающие взаимодействие с HTTP-запросами и HTTP-ответами, инфраструктура Web-форм, поддержка тем и профилирования, Web-части и т.д.)

• Web-формы и HTML-элементы

• Web-разработка для мобильных платформ

• Web-сервисы XML

В этой книге тема разработки .NET-приложений (ни Web-приложений, ни каких-то других) для мобильных систем не рассматривается, но роль Web-сервисов XML будет обсуждаться в главе 25. В табл. 23.1 предлагаются описания некоторых базовых пространств имен ASP.NET 2.0.

Таблица 23.1. Пространства имен ASP.NET для Web

Web-страницы ASP.NET могут строиться с использованием одного из двух подходов. Вы можете создать один файл *.aspx, который будет содержать комбинацию программного кода сервера и HTML (по примеру классической технологии ASP). Для создания такого файла используется модель одномодульной страницы, когда программный код сервера размещается в контексте ‹script›, но сам этот программный код непосредственно не является программным кодом сценария (например, на языке VBScript или JavaScript). Вместо этого операторы программного кода в рамках блока ‹script› записываются на любом из управляемых языков (C#, Visual Basic .NET и т.д.).

Если создаваемая страница содержит очень мало программного кода (и очень много HTML-кода), модель одномодульной страницы окажется лучшим вариантом выбора, так как перед вами а одном унифицированном файле *. aspx будут и программный код, и разметка. Размещение программного и HTML-кода в одном файле *.aspx обеспечивает и другие преимущества.

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

• Ввиду отсутствия зависимости между файлами, одномодульную страницу проще переименовать.

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

Подход, принятый в Visual Studio 2005 по умолчанию (при создании нового проекта Web-узла), использует так называемую технологию внешнего кода поддержки (code-behind), предполагающую отделение программного кода от HTML-логики представления и размещение их в двух разных файлах. Эта модель исключительно хорошо работает в тех случаях, когда ваши страницы содержат большие объемы программного кода или в процессе разработки Web-узла принимают участие много разработчиков. Модель, основанная на использовании внешнего кода поддержки, имеет несколько преимуществ.

• Ввиду совершенного разделения HTML-разметки и программного кода, становится возможным, чтобы созданием разметки занимались дизайнеры, а созданием программного кода C# – программисты.

• Программный код не предъявляется дизайнерам страницы и другим разработчикам, занимающимся только разметкой страницы (вы, наверное, догадываетесь, что разработчики HTML обычно не проявляют большого интереса к огромным объемам программного кода C#).

• Файлы программного кода могут использоваться в множестве файлов *.aspx.

Выбранный вами подход не влияет на производительность полученного результата. Также следует подчеркнуть, что одномодульная модель *.aspx, которая в .NET 1.x провозглашалась неприемлемой, теперь такой не считается. Теперь во многих Web-приложениях ASP.NET 2.0 при построении узлов используются преимущества обеих указанных выше моделей.

Сначала мы рассмотрим модель одномодульной страницы. Нашей целью является построение файла *.aspx (с именем Default.aspx), который будет отображать таблицу Inventory базы данных Cars (созданной в главе 22). Вполне возможно создать эту страницу только с помощью редактора Блокнот, но Visual Studio 2005 может упростить процесс построения с помощью средств IntelliSense, автоматического завершения программного кода и визуальных редакторов страницы.

Сначала откройте Visual Studio 2005 и создайте новую Web-форму, выбрав File>New>File из меню (рис. 23.8).

После загрузки страницы в среду разработки обратите внимание на то, что в нижней части окна проектирования страницы есть две кнопки, позволяющие увидеть содержимое файла *.aspx в двух разных вариантах. Выбрав кнопку Design, вы увидите окно визуального проектирования, в котором вы можете строить пользовательский интерфейс страницы во многом подобно тому, как вы строили интерфейс формы приложения Windows Form (перетаскивая элементы управления на поверхность формы, изменяя настройки в окне свойств и т.д.). Если выбрать кнопку Source, вы увидите HTML-код и блоки ‹script›, из которых скомпонован данный файл *.aspx.

Рис. 23.8. Создание нового файла *.aspx

Замечание. В отличие от более ранних версий Visual Studio, вид Source в Visual Studio 2005 предлагает полноценную поддержку IntelliSense и позволяет перетаскивание элементов пользовательского интерфейса непосредственно в окно HTML-кода.

В панели инструментов (окно Toolbox) Visual Studio 2005 откройте раздел Standard и перетащите элементы управления Button, Label и GridView в окно проектирования страницы (элемент GridView можно найти в разделе Data окна Toolbox). He пренебрегайте использованием окна свойств (или IntelliSense для HTML) при установке различных свойств элементов интерфейса и укажите для каждого Web-элемента подходящее имя с помощью свойства ID. На рис. 23.9 показан один из возможных вариантов оформления проекта (сдержанность здесь проявляется преднамеренно, чтобы минимизировать объем генерируемого кода разметки).

Рис. 23.9. Пользовательский интерфейс Default.aspx

Теперь щелкните на кнопке Source внизу окна и найдите в программном коде раздел ‹form› своей страницы. Обратите внимание на то, что Web-элементы управления определены с помощью дескриптора ‹asp:›, там же вы обнаружите набор пар имен и значений в соответствии с установками, сделанными вами в окне свойств.

‹form id="form1" runat="server"›

 ‹div›

  ‹asp:Label ID="lblInfo" runat="server" Техt="Щелкните на кнопке, чтобы заполнить таблицу"›

  ‹/asp:Label›

  ‹asp:GridView ID="carsGridView" runat="server"›

  ‹/asp:GridView›

  ‹asp:Button ID="btnFillData" runat="server" Text="Заполнить таблицу" /›

 ‹/div›

‹/form›

Подробности использования Web-элементов управления ASP.NET будут обсуждаться в главе позже. Пока что достаточно понять, что Web-элементы управления – это классы, обрабатываемые на Web-сервере и автоматически помещающие свое HTML-представление в исходящий HTTP-ответ (да, вам не нужно создавать соответствующий HTML-код!).

Кроме этого основного преимущества, Web-элементы ASP.NET поддерживают модель программирования, аналогичную Windows Forms, когда имена свойств, методов и событий имитируют их эквиваленты в Windows Forms. Для примера обработайте событие Click для типа Button либо с помощью окна свойств (используйте кнопку с пиктограммой молнии), находясь Visual Studio в режиме проектирования Web-формы, либо с помощью раскрывающихся списков, размещенных в верхней части окна просмотра программного кода (кнопка Source). В результате в определение Button будет добавлен атрибут OnClick, которому назначено имя обработчика события Click.

‹asp:Button ID="btnFillData" runat="server" Text="Заполнить таблицу" OnClick="btnFillData_Click" /›

Кроме того, в ваш блок ‹script› добавляется обработчик события Click сервера (здесь обратите внимание на то, что входные параметры в точности соответствуют требованиям целевого делегата System.EventHandler),

‹script runat="server"›

protected void btnFillData_Click(object sender, EventArgs e) {}

‹/script›

Реализуйте серверную часть обработчика событий так, чтобы использовался объект чтения данных ADO.NET для заполнения GridView. Также добавьте директиву импорта (подробнее об этом чуть позже), которая укажет, что вы используете пространство имен System.Data.SqlClient. Вот остальная часть соответствующей программной логики страницы файла Default.aspx.

‹%@Page Language="C#" %›

‹%@Import Namespace = "System.Data.SqlClient" %›

…

‹script runat="server"›

protected void btnFillData_Click(object sender, EventArgs е) {

 SqlConnection_: sqlConn = new SqlConnection("Data Source=.;Initial Catalog=Cars;UID=sa;PWD=");

 sqlConn.Open();

 SqlCommand cmd = new SqlCommand("Select * From Inventory", sqlConn);

 carGridView.DataSource = cmd.ExecuteReader();

 carsGridView.DataBind();

 sqlConn.Close();

}

‹/script›

‹html xmlns = "http://www.w3.org/1999/xhtml"›

 …

‹/html›

Перед тем как погрузиться в детали обсуждения формата этого файла *.aspx, давайте выполним тестовый запуск страницы. Откройте окно командной строки Visual Studio 2005 и запустите утилиту WebDev.WebServer.exe, указав путь к сохраненному вами файлу Default.aspx.

webdev.webserver.exe /port:12345 /path:"C:\CodeTests\SinglePageModel"

Затем, открыв любой браузер, введите следующий адрес URL.

http://localhost:12345/

При загрузке страницы вы сначала увидите только типы Label и Button. Но когда вы щелкнете на кнопке, Web-серверу будет направлен вторичный запрос, в результате которого Web-элементы управления получат обратно соответствующие HTML-дескрипторы. На рис. 23.10 показан результат визуализации нашей страницы в окне Mozilla Firefox.

Рис. 23.10. Web-доступ к данным

Совсем просто, не правда ли? Но, как говорится, все зависит от мелочей, так что давайте рассмотрим немного подробнее композицию файла *.aspx.

Прежде всего следует отметить то, что файл *.aspx обычно открывается набором директив. Директивы ASP.NET всегда обозначаются маркерами ‹%@ XXX %› и могут сопровождаться различными атрибутами, информирующими среду выполнения ASP.NET о том, как обрабатывать соответствующие данные.

Каждый файл *.aspx должен иметь, как минимум, директиву ‹%@Page%›, которая используется для определения управляемого языка, применяемого в рамках страницы (для этого используется атрибут language). Также директива ‹%@Page%› может определять имя соответствующего файла с внешним кодом поддержки (если таковой имеется), разрешать трассировку и т.д. Наиболее интересные атрибуты ‹%@Page%› описаны в табл. 23.2.

Таблица 23.2. Подборка атрибутов директивы ‹%@Page%›

В дополнение к директиве ‹%@Page%› файл *.aspx может использовать различные директивы ‹%@Import%›, чтобы явно указать пространства имен, необходимые для текущей страницы. В нашем примере указано использование типов из пространства имен System.Data.SqlClient. Ясно, что при необходимости использования дополнительных пространств имен .NET нужно просто указать несколько директив ‹%@Import%›.

Замечание. Директива ‹%@lmport%› не является необходимой, если применяется модель страницы с внешним кодом поддержки. При использовании файла с внешним кодом поддержки для указания внешних пространств имен применяется ключевое слово using C#.

Опираясь на имеющиеся у вас знания .NET, вы можете поинтересоваться, почему в файле *.aspx нет указаний на пространства имен System.Data и System. Причина в том, что все страницы *.aspx автоматически получают доступ в ряду ключевых пространств имен, включай следующие.

• System

• System.Collections

• System.Collections.Generic

• System.Configuration

• System.IO

• System.Text

• System.Text.RegularExpressions

• Все пространства имен, связанные с System.Web

ASP.NET определяет ряд других директив, которые могут встречаться в файлах *.aspx как до, так и после ‹%Page%› и ‹%@Import%›, но их обсуждение предполагается привести позже.

В соответствии с моделью одномодульной страницы файл *.aspx может содержать логику сценария серверной стороны, который должен выполняться на Web-сервере. Блоки программного кода, определенные для сервера, должны выполняться на сервере, поэтому для них используется атрибут runat="server". Если атрибут runat="server" не указан, среда выполнения предполагает, что соответствующий блок является сценарием клиента, который следует отправить с исходящим HTTP-ответом.

‹script runat="server"›

protected void btnFillData_Click(object Sender, EventArgs e) {}

‹/script›

Сигнатура этого вспомогательного метода должна выглядеть очень знакомой. Вспомните, что при изучении Windows Forms говорилось о том, что обработчик события должен соответствовать шаблону, определенному соответствующим делегатом .NET. А когда вы хотите обработать щелчок на кнопке со стороны сервера, соответствующим делегатом является System.EventHandler, который, как вы помните, может вызвать только методы, получающие в качестве первого параметра System.Object, а в качестве второго – System.EventArgs.

Последним из рассматриваемых здесь вопросов является структура определения элементов управления Button, Label и GridView Web-формы. Подобно ASP и HTML, Web-элементы ASP.NET размещаются в контексте ‹form›. Но в этом случае открывающий дескриптор ‹form› сопровождается атрибутом runat="server". Это очень важно, поскольку тем самым дескриптор информирует среду выполнения ASP.NET о том, что перед размещением HTML-кода в потоке ответа соответствующие элементы ASP.NET должны получить возможность обновить свое HTML-представление.

‹form id="form1" runat="server"›

...

‹/form›

Исходный код. Файл примера SinglePageModel размещен в подкаталоге, соответствующем главе 23.

Чтобы продемонстрировать возможности модели страницы с внешним кодом поддержки, мы воссоздадим предыдущий пример, используя шаблон Web-узла Visual Studio 2005 (при этом важно понимать, что для создания страниц с внешним кодом поддержки использовать Visual Studio 2005 совсем не обязательно). Выбрав File>New>Web Site из меню, укажите шаблон ASP.NET Web Site (рис. 23.11).

Рис. 23.11. Шаблон ASP.NET Web Site в Visual Studio 2005

На рис 23.11 обратите внимание на то, что вы можете сразу указать место расположения нового узла. При выборе File System ваши файлы будут размещены в пределах одного локального каталога, и страницы будут обслуживаться с помощью WebDev.WebServer.exe. Если выбрать FTP или HTTP, узел будет обслуживаться в рамках виртуального каталога, поддерживаемого IIS. Для нашего примера нет никакой разницы, какую из возможностей вы выберете, но для простоты давайте выберем File System.

Замечание. При создании Web-узла ASP.NET В Visual Studio 2005 соответствующий файл решения, (*.sln) по умолчанию размещается в лапке Мои документы\Visual Studio 2005\Projects. Файлы содержимого узла (такие как, например, *.аspx) будут находиться в указанном локальном каталоге или (при использовании IIS) в физическом файле, отображающемся в виртуальный каталог.

Снова используйте окно проектирования для построения пользовательского интерфейса, состоящего из Label, Button и GridView, и используйте окно свойств для изменения настроек. Теперь щелкните на кнопке Source внизу окна, чтобы увидеть окно программного вода, и вы увидите ожидаемые дескрипторы ‹asp› и ‹/asp›. Также обратите внимание на то, что директива ‹%@Page%› в данном случае имеет два новых атрибута.

‹*@Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %›

Атрибут CodeFile используется для указания связанного внешнего файла, содержащего программную логику страницы. По умолчанию имена файлов с внешним кодом поддержки образуются путем добавления суффикса.сs к имени файла *.aspx (скажем, в нашем примере это Default.aspx.cs). Если заглянуть в окно Solution Explorer, вы увидите файл с внешним кодом поддержки в рамках узла Web-формы (рис. 23.12).

Рис. 23.12. Файл с внешним кодом поддержки, ассоциированный с файлом *.aspx.

Замечание. Атрибут Codebehind, предлагавшийся в ASP.NET 1.x, в рамках директивы ‹!@Page%› больше не поддерживается.

Кроме ряда операторов using для указания связанных с Web пространств имен, ваш файл внешнего программного кода определяет класс с модификатором partial, производный от System.Web.UI.Page. Обратите внимание на то, что имя этого класса (_Dеfault) идентично значению атрибута inherits, указанного в рамках директивы ‹%@Page%› (подробнее о Page_Load() мы поговорим в этой главе немного позже).

public partial class _Default : System.Web.UI.Page {

 protected void Page_Load(object sender, EventArgs e) {

 }

}

Обработайте событие Click для типа Button (снова аналогично приложениям Windows Forms). Как и раньше, в определение Button будет добавлен атрибут OnClick. Однако теперь обработчик события сервера уже не размещается в контексте ‹script› файла *.aspx, а оказывается методом типа класса _Default. В завершение построения примера добавьте оператор using для System.Data.SqlClient в файл с внешним кодом поддержки и реализуйте программу обработки в соответствии с предыдущей программной логикой ADO.NET.

protected void btnFillGrid_Click(object sender, EventArgs e) {

 SqlConnection sqlConn = new SqlConnection("Data Source=.;Initial Catalog=Cars;UID=sa;PWD");

 sqlConn.Open();

 SqlCommand cmd = new SqlCommand("Select * From Inventory", sqlConn);

 carsGridView.DataSource = cmd.ExecuteReader();

 carsGridView.DataBind();

 sqlConn.Close();

}

Если при создании проекта вы выбрали вариант File System, то при выполнении Web-приложения автоматически cтартует WebDev.WebServer.exe (очевидно, что при выборе IIS этого не будет). В любом случае используемый по умолчанию браузер должен отобразить содержимое страницы.

Вообще говоря, при создании Web-проекта ASP.NET вы можете использовать те же средства отладки, что и при создании любого другого проекта в Visual Studio 2005. Так, вы можете устанавливать контрольные точки в файле внешнего кода поддержки (и в блоках script файла *.aspx), запускать сеанс отладки (по умолчанию для этого используется клавиша ‹F5›) и использовать режим пошагового выполнения программного кода.

Но, чтобы выполнять отладку Web-приложения ASP.NET, ваш узел должен содержать правильно скомпонованный файл Web.config. В главе 24 структура файлов Web.config рассматривается подробнее, но, по существу, эти XML-файлы служат той же цели, что и файл app.config выполняемого компоновочного блока. Если ваш проект еще не содержит файла Web.config, Visual Studio 2005 это обнаружит и добавит такой файл в ваш проект. Соответствующим элементом является ‹compilation›.

‹configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"›

 …

 ‹system.web›

  ‹compilation debug="true"/›

 ‹/system.web›

‹/configuration›

Вы также можете разрешить поддержку трассировки для файла *.aspx, установив для атрибута Trace значение true (истина) в рамках директивы ‹%@Page%›.

‹%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Trace="true" %›

В результате генерируемый HTML-код будет содержать многочисленные подробности, касающиеся предыдущего цикла запроса/ответа HTTP (переменные сервера, сеанса, приложения и т.д.). Чтобы добавить к ним свои собственные сообщения трассировки, можете использовать свойство Trace типа System.Web.UI.Page. В любое время, когда вы пожелаете записать пользовательское сообщение (из блока сценария или файла исходного вода C#), просто вызовите метод Write().

protected void btnFillGrid_Click(object Sender, EventArgs e) {

 …

 // Генерирование пользовательского сообщения трассировки.

 Trace.Write("Моя категория", "Конец заполнения таблицы");

}

Если теперь запустить проект и направить вторичное обращение Web-серверу, вы увидите свою пользовательскую категорию и пользовательское сообщение ближе к концу раздела трассировки перед разделом Control Tree (рис. 23.13).

Рис. 23.13. Запись пользовательских сообщений трассировки

Исходный код. Файл примера CodeBehindPageModel размещен в подкаталоге, соответствующем главе 23.

Если у вас есть опыт создания Web-приложений с использованием ASP.NET 1.x, для вас можете показаться весьма удивительным то, что множество привычных для вас файлов (Web.config, Global.asax, AssemblyInfo.cs и т.д.) новый Web-узел не включает. Кроме того, шаблон Web Site предлагает папку App_Data, но, кажется, в окне Solution Explorer отсутствует папка References.

Прежде всего, следует подчеркнуть, что файлы Web.config И Global.asax, конечно же, в ASP.NET 2.0 поддерживаются, но вам нужно явно добавить их в проект, выбрав WebSite>Add New Item из меню.

В главе 24 будет рассмотрена роль этих двух файлов, поэтому пока что о деталях не беспокойтесь. Знайте также, что вы можете добавить для Web-узла любое число ссылок на внешние компоновочные блоки .NET с помощью выбора WebSite>Add Reference из меню (при этом, как мы позже убедимся, результат будет немного отличаться от интуитивно ожидаемого).

Другим существенным отличием новой схемы Web-приложений является то, что в Visual Studio 2005 Web-узлы могут содержать целый ряд подкаталогов со специальными именами, имеющими специальные значения в среде выполнения ASP.NET. Эти "специальные подкаталоги" описаны в табл. 23.3.

Таблица 23.3. Специальные подкаталоги ASP.NET 2.0

Добавить любую из этих подпапок в Web-приложение можно явно, выбрав WebSite>Add Folder из меню. Но во многих случаях это сделает сама среда разработки, как только вы "естественным образом" добавите соответствующий файл (например, при добавлении в систему узла нового файла C#, автоматически в структуру каталогов добавляется папка App_Code, если она в этот момент не существует).

Позже вы увидите, что Web-страницы ASP.NET в конечном счете компилируются в компоновочный блок .NET. Поэтому не должно быть неожиданностью то, что Web-узлы могут ссылаться на любое число приватных или общедоступных компоновочных блоков, В ASP.NET 2.0 метод указания внешних компоновочных блоков, необходимых для данного узла, в корне отличается от того, что предлагалось в рамках ASP.NET 1.x. Причина такого изменения в том, что теперь в Visual Studio 2005 Web-узлы трактуются в беспроектной форме.

Хотя шаблон Web Site и генерирует файл *.sln, с помощью которого можно загрузить файлы *.aspx в среду разработки, связанного с ним файла *.csproj не существует. Вы, возможно, знаете, что проект Web-приложения ASP.NET 1.x записывал информацию обо всех внешних компоновочных блоках в файл *.csproj. Этот факт порождает резонный вопрос: "Где хранится информация о внешних компоновочных блоках в ASP.NET 2.0?"

Когда вы ссылаетесь на приватный компоновочный блок, Visual Studio 2005 автоматически создает каталог Bin в структуре каталогов приложения, чтобы сохранить там локальную копию двоичного файла. При использовании вашим программным кодом типов из соответствующих библиотек программного кода они автоматически загружаются по первому запросу. Для проверки активизируйте меню WebSite>Add Reference и выберите любой (но не строго именованный) файл *.dll из тех, которые вы создали в процессе изучения текста этой книги, и вы обнаружите, что в окне Solution Explorer отображается папка Bin (рис. 23.14).

Рис. 23.14. Папка Bin содержит копии всех приватных компоновочных блоков, на которые ссылается приложение

Если же вы ссылаетесь на общедоступный компоновочный блок, Visual Studio 2006 автоматически добавляет в текущее Web-решение файл web.config (если его еще нет) и записывает внешнюю ссылку в рамках элемента ‹assemblies›. Так, если снова активизировать меню Site>Add Reference, но на этот раз выбрать общедоступный компоновочный блек (например. System.Drawing.dll), то вы обнаружите, что ваш файл Web.config примет следующий вид.

‹?xml version="1.0"?›

‹configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"›

 ‹appSettings/›

 ‹connectionStrings/›

 ‹system.web›

  ‹compilation debug="false"›

   ‹assemblies›

    ‹add assembly="System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/›

   ‹/assemblies›

  ‹/compilation›

  ‹authentication mode="Windows"/›

 ‹/system.web›

‹/configuration›

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

Папка App_Code используется для хранения файлов исходного кода, которые не привязаны непосредственно к конкретной Web-странице (как файлы с внешним кодом поддержки), но которые все равно должны компилироваться для использования вашим Web-узлом. Программный код из папки App_Code будет автоматически компилироваться в фоновом режиме по мере необходимости. После этого соответствующий компоновочный блок становится доступным любому другому программному коду Web-узла. В этом смысле папка App_Code во многом подобна папке Bin, за исключением того, что здесь вы можете сохранить исходный код вместо скомпилированного программного кода. Главным преимуществом такого подхода является то, что оказывается возможным определить пользовательские типы для Web-приложения без необходимости компилировать их независимо.

Одна папка App_Code может содержать файлы программного кода, созданные на разных языках. В среде выполнения подходящий компилятор сгенерирует нужный компоновочный блок. Если же вы предпочитаете хранить такие файлы программного кода раздельно, можете определить множество подкаталогов для хранения файлов с управляемым программным кодом разного типа (*.cs, *.vb и т.д.).

Для примера предположим, что вы добавили в корневой каталог приложения Web-узла папку App_Code, содержащую две подпапки (MyCSharpCode и MyVbNetCode), которые содержат файлы, написанные на соответствующих языках. После этого вы можете создать файл Web.config, который указывает на эти подпапки с помощью элемента ‹codeSubDirectories›.

‹?xml version="1.0"?›

‹configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"›

 ‹appSettings/›

 ‹connectionStrings/›

 ‹system.web›

  ‹compilation debug="false"›

   ‹assemblies›

    ‹add assembly="System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/›

   ‹/assemblies›

   ‹codeSubDirectories›

    ‹add directoryName="MyCSharpCode" /›

    ‹add directoryName="MyVbNetCode" /›

   ‹/codeSubDirectories›

  ‹/compilation›

  ‹authentication mode="Windows"/›

 ‹/system.web›

‹/configuration›

Замечание. Папка App_Code часто используется и для хранения файлов, которые не являются файлами c программным кодом на конкретном языке, но тоже оказываются необходимыми (например, файлы *.xsd, *.wsdl и т.д).

Независимо от того, какую модель страницы вы использовали (одномодульную страницу или страницу с внешним кодом поддержки), ваши файлы *.aspx (как и любые связанные файлы с кодом поддержки) динамически компилируются в действительный компоновочный блок .NET. Этот компоновочный блок затем обрабатывается в рамках рабочего процесса ASP.NET (aspnet_wp.exe) в пределах собственного домена приложения (для получения более подробной информации о доменах приложений см. главу 13). Однако метод компиляции компоновочного блока Web-узла в ASP.NET 2.0 оказывается совершенно иным.

При использовании модели одномодульной страницы, HTML-разметка, блоки ‹script› и определения Web-элементов управления динамически компилируются в тип класса, производный от System.Web.UI.Page.

Имя этого класса получается из имени файла *.aspx с помощью присоединения суффикса _аspx к имени файла (например, страница MyPage.aspx порождает тип класса с именем MyPage_aspx). На рис. 23.15 показана общая схема соответствующего процесса.

Рис. 23.15. Модель компиляции одномодульных страниц

Этот динамически компилируемый компоновочный блок устанавливается в определенный средой выполнения подкаталог в папке ‹%windir%›Microsoft.NET\ Framework\v2.0.50215\Temporary ASP.NET Files\root. Имя пути после \root зависит от целого ряда факторов (хеш-кода и т.п.). но в конце концов там можно найти соответствующие файлы *.dll (и файлы поддержки). На рис. 23.16 показан пример одного такого компоновочного блока.

Рис. 23.16. Автоматически сгенерированный компоновочный блок ASP.NET

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

Взглянув на предыдущий пример CodeBehindPageModel, вспомните о том, что файл Default.aspx связывается с парциальным классом _Default, размещенным в файле внешнего кода поддержки. Если вы имеете опыт работы с ASP.NET 1.x, то можете спросить, что же при этом происходит с описаниями членов-переменных для различных Web-элементов управления и с программным кодом в пределах InitializeComponent(), в частности с программной логикой обработки событий. В ASP.NET 2.0 все это собирается в третьем "файле", генерируемом в памяти. Фактически это не совсем файл, а представление парциального класса в памяти (рис. 23.17).

В рамках этой модели объявленные в файле *.aspx Web-элементы управления используются для построения дополнительного парциального класса, определяющего все члены-переменные интерфейса пользователя и программную логику конфигурации, которые в ASP.NET 1.x обычно находились в пределах метода InitializeComponent(), а в данном случае остаются для нас невидимыми. Этот парциальный класс в процессе компиляции объединяется с файлом внешнего кода поддержки, чтобы в результате получился базовый класс генерируемого типа класса _aspx (в модели компиляции одномодульной страницы генерируемый файл _aspx получается непосредственно из System.Web.UI.Page).

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

Рис. 23.17. Модель компиляции многомодульных страниц

Замечание. В ASP.NET 2.0 теперь можно выполнить предкомпиляцию всех (или некоторого подмножества) страниц Web-узла с помощью специального инструмента командной строки aspnet_compiler.exe. Более конкретная информация по этому вопросу имеется в документации .NET Framework 2.0 SDK.

Как вы только что убедились, готовый генерируемый класс, представляющий файл *.aspx, получается из System.Web.UI.Page. Подобно любому базовому классу, этот тип обеспечивает полиморфный интерфейс всем производным типам. Однако тип Page является не единственным членом в иерархии наследования. Если найти тип Page (в пределах компоновочного блока System.Web.dll) в окне обозреватели объектов Visual Studio 2005, то вы увидите, что этот тип "принадлежит" типу TemplateControl, который, в свою очередь, "принадлежит" Control, а последний "принадлежит" Object (рис. 23.18).

Вы должны догадываться, что каждый из этих базовых классов вносит в файл *.aspx свой "немалый вклад" в отношении функциональных возможностей. Для большинства проектов вы будете использовать члены, определенные в рамках родительских классов Page и Control. Вообще говоря, функциональные возможности, приобретенные от класса System.Web.UI.TemplateControl, могут представлять для вас интерес только при построении пользовательских элементов управления Web Form и при взаимодействии с процессом визуализации. С этими оговорками давайте рассмотрим роль типа Page.

Рис. 23.18. Происхождение страницы ASP.NET

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

Таблица 23.4. Свойства типа Page

Вы уже видели выше, что основной поток Web-сеанса начинается с регистрации клиента, ввода пользовательской информации и щелчка на кнопке Отправить, в результате чего данные HTML-формы направляются Web-странице для обработки. В большинстве случаев открывающий дескриптор form содержит атрибуты action и method, указывающие файл на Web-сервере, который должен обеспечить данные различным HTML-элементам, и метод пересылки этих данных (GET или POST).

‹form name="defaultPage" id="defaultPage" action="http://localhost/Cars/ClassicAspPage.asp" method = "GET"›

‹/form›

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

Таблица 23.5. Члены типа HttpRequest 

В дополнение к этим свойствам тип HttpRequest предлагает ряд полезных методов, включая следующие.

• MapPath(). Отображает виртуальный путь запрошенного адреса URL в физический путь на сервере для текущего запроса.

• SaveAs(). Сохраняет информацию текущего HTTP-запроса в файл на Web-сервере (что может оказаться полезным при отладке).

• ValidateInput(). Если с помощью атрибута Validate соответствующей директивы страницы разрешена возможность контроля данных, то этот метод может вызываться для проверки всех вводимых пользователем данных (включая данные cookie) на случай выявления потенциально опасных вариантов ввода (из предусмотренного списка таких вариантов).

Первый интересным элементом типа HttpRequest является свойство Browser, обеспечивающее доступ к базовому объекту HttpBrowserCapabilities. Объект HttpBrowserCapabilities, в свою очередь, предлагает множество членов, которые позволяют программно исследовать статистику браузера, отправившего поступивший HTTP-запрос.

Создайте новый Web-узел ASP.NET с именем FunWithPageMembers. Нашим первым заданием будет построение пользовательского интерфейса, позволяющего при щелчке пользователя на Web-элементе управления Button увидеть различную информацию о вызывающем браузере. Эта информация будет генерироваться динамически и присваиваться типу Label (с именем lblOutput). Обработчик события Click для Button будет таким.

protected void btnGetBrowserStats_Click(object sender, System.EventArgs e) {

 string theInfo = "";

 theInfo += String.Format ("‹li›Это клиент AOL? {0}", Request.Browser.AOL);

 theInfo += String.Format("‹li›Поддерживает ли клиент ActiveX? {0}", Request.Browser.ActiveXControls);

 theInfo += String.Format("‹li›Это клиент Beta? {0}", Request.Browser.Beta);

 theInfo += String.Format("‹li›Поддерживает ли клиент Java? {0}", Request.Browser.JavaApplets);

 theInfo += String.Format("‹li›Поддерживает ли клиент cookie? {0}", Request.Browser.Cookies);

 theInfo += String.Format("‹li›Поддерживает ли клиент VBScript? {0}", Request.Browser.VBScript);

 lblOutput.Text = theInfo;

}

Здесь проверяется целый ряд возможностей браузера. Как вы можете догадываться, очень важно выяснить возможность поддержки браузером элементов управления ActiveX, апплетов Java и VBScript клиента. Если вызывающий браузер не поддерживает какую-то из Web-технологий, ваша страница *.aspx должна быть готова выполнить альтернативный план действий.

Другими элементами типа HttpResponse являются свойства Form и QueryString. Эти два свойства функционируют аналогично классическому варианту ASP и позволяют анализировать поступающие данные формы, используя пары имен и значений. Вспомните из нашего предыдущего обсуждения классической технологии ASP о том, что при отправке HTTP-данных с помощью GET данные формы будут доступны через свойство QueryString, тогда как для доступа к данным, представленным с помощью POST, используется свойство Form.

Для доступа к данным формы клиента на Web-сервере, конечно, можно использовать свойства HttpRequest.Form и HttpRequest.QueryString, но этот устаревший подход (в большинстве случаев) не является необходимым. Ввиду того, что ASP.NET предлагает свои собственные Web-элементы управления серверной стороны, у вас есть возможность обращаться с HTML-элементами интерфейса, как с настоящими объектами. Таким образом, вместо получения значения текстового блока в варианте

protected void btnGetFormData_Click(object sender, EventArgs e) {

 // Получение значения для элемента с ID=txtFirstName.

 string firstName = Request.Form["txtFirstName"];

}

вы можете напрямую запросить свойство Text серверного элемента управления.

protested void btnGetFormData_Click(object sender, EventArgs e) {

 // Получение значения для элемента с ID=txtFirstName.

 string firstName = txtFirstName.Text;

}

Этот подход не только соответствует строгим принципам ООП, но при этом вообще не приходится заботиться о том, как представляются данные формы (GET или POST). К тому же непосредственная работа с элементом управления гораздо больше соответствует требованиям типовой безопасности, поскольку здесь возможные ошибки ввода будут выявлены уже на этапе компиляции, а не в среде выполнения. Конечно, это не значит, что вам в ASP.NET вообще никогда не придется использовать свойства Form и QueryString, но необходимость в их использовании существенно уменьшится.

Еще одним очень важным членом HttpRequest является свойство IsPostBack. Напомним, что "postback" обозначает вторичное обращение к конкретной Web-странице в ходе одного сеанса связи с сервером. С учетом этого должно быть понятно, что свойство IsPostBack возвращает true (истина), если текущий HTTP-запрос отправлен уже зарегистрированным настоящий момент пользователем, и false (ложь), если это первое взаимодействие пользователя со страницей.

Обычно необходимость в определении того, что текущий HTTP-запрос является вторичным, возникает тогда, когда некоторый блок программного кода должен выполняться только при первом обращении пользователя к странице. Например, при первом доступе пользователя к файлу *.aspx вы можете заполнить некоторый объект DataSet ADO.NET и поместить этот объект в кэш для использования в дальнейшем. Когда вызывающая сторона снова обратится к той же странице, вы можете избежать необходимости нового обращения к базе данных (конечно, некоторые страницы могут требовать, чтобы DataSet обновлялся при каждом запросе, но это уже другая проблема).

protected void Page_Load(objeet sender, EventArgs e) {

 // DataSet заполняется только при первом обращении

 // пользователя к данной странице.

 if (!IsPostBack) {

  // Заполнение DataSet и отправка в кэш!

 }

 // Использование DataSet из кэша.

}

Теперь вы понимаете, как тип Page взаимодействует с поступающим HTTP-за-просом, и следующим шагом должно быть выяснение того, как реализуется взаимодействие с исходящим HTTP-ответом. В ASP.NET свойство Response класса Page обеспечивает доступ к экземпляру типа HttpResponse. Этот тип определяет ряд свойств, позволяющих сформировать HTTP-ответ, отправляемый обратно браузеру клиента. Описания базовых свойств этого типа предлагаются в табл. 23.6.

Таблица 23.6. Свойства типа HttpResponse

Рассмотрите также описания некоторых методов типа HttpResponse, представленные в табл. 23.7.

Таблица 23.7. Методы типа HttpResponse

Пожалуй, самой известной сферой применения типа HttpResponse является запись содержимого непосредственно в выходной поток HTTP. Метод HttpResponse. Write() позволяет передать HTML-дескрипторы, или вообще любые строковые литералы. Метод HttpResponse.WriteFile() расширяет эти возможности с тем, чтобы вы могли указать имя физического файла на Web-сервере, содержащего данные, направляемые в выходной поток (это оказывается очень удобным в том случае, когда требуется отправить содержимое уже существующего файла *.htm).

Для примера предположим, что вы добавили в свой файл *.aspx еще один тип Button, который реализует обработчик события Click сервера так.

protected void btnHttpResponse_Click(object sender, EventArgs e) {

 Response.Write("‹b›Moe имя :‹/b›‹br›");

 Response.Write(this.ToString());

 Response.Write("‹br›‹br›‹b›Boт Ваш последний запрос:‹/b›‹br›");

 Response.WriteFile("MyHTMLPage.htm");

}

Роль этой вспомогательной функции (которая может вызываться некоторым: обработчиком события на стороне сервера) очень проста. Единственным заслуживающим внимания моментам здесь является то, что метод HttpResponse. WriteFile() теперь отправляет содержимое файла *.htm сервера из корневого каталога Web-узла.

Снова подчеркнем, что вы, конечно, можете использовать подход "старой школы", чтобы отображать HTML-дескрипторы и содержимое, используя метод Write(), но этот подход в рамках ASP.NET применяется гораздо реже, чем в рамках классической технологии ASP. Причина здесь (снова) в наличии серверных Web-элементов управления. Скажем, чтобы отобразить блок текстовых данных в браузере, достаточно просто присвоить подходящее значение свойству Text элемента Label.

Другой возможностью типа HttpResponse является перенаправление пользователя по новому адресу URL.

protected void btnSomeTraining_Click(object sender, EventArgs e) {

 Response.Redirect("http://www.IntertechTraining.com");

}

Если этот обработчик событий вызвать с помощью вторичного обращения клиента к серверу, пользователь будет автоматически перенаправлен по указанному URL.

Замечание. Вызов метода HttpResponse.Redirect() всегда влечет за собой обращение к браузеру клиента. Если нужно просто передать управление файлу *.aspx в том же виртуальном каталоге, более эффективным будет вызов метода HttpServerUtility.Transfer() (доступного через наследуемое свойство Server).

На этом мы завершим обсуждение функциональных возможностей System.Web.UI.Page. Чуть позже мы рассмотрим роль базового класса System.Web.UI.Control, однако нашим следующим заданием будет исследование цикла существования объектов, производных от Page.

Исходный код. Файлы примера FunWithPageMembers размещены в подкаталоге, соответствующем главе 23.

Каждая Web-страница ASP.NET имеет свой "жизненный цикл". Когда среда выполнения ASP.NET получает входящий запрос для данного файла *. aspx, в памяти размещается соответствующий тип, производный от System.Web.UI.Page, для создания которого используется конструктор, заданный по умолчанию. После этого среда обработки автоматически генерирует серию событий.

По умолчанию сгенерированная в Visual Studio 2005 страница с внешним кодом поддержки определяет обработчик события Load страницы.

public partial class _Default: System.Web.UI.Page {

 protected void Page_Load(object sender, EventArgs e) {

 }

}

Кроме события Load, тип Page может выполнять перехват любого из событий, указанных в табл. 23.8 в том порядке, в котором эти события возникают.

Таблица 23.8. События типа Page

Замечание. Все события типа Page работают с делегатом System.EventHandler.

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

protected Page_nameOfTheEvent(object sender, EventArgs e)

Например, cобытие Unload можно обработать так.

public partial class _Default: System.Web.UI.Page {

 protected void Page_Load(object sender, EventArgs e) {

 }

 protected void Page_Unload(object sender, EventArgs e) {

 }

}

Этот метод, как по волшебству, вызывается при выгрузке страницы (несмотря на то, что вы не применяли синтаксис событий C#), поскольку атрибут AutoEventWireUp устанавливается равным true (истина) по умолчанию в директиве ‹%@Page%› вашего файла *.aspx.

‹%@ Page Language="C#"

AutoEventWireup="true"

CodeFile="Default.aspx.cs" Inherits="_Default" %›

Как подсказывает имя этого атрибута, при его активизации будет создана необходимая оснастка событий в рамках автоматически генерируемого парциального класса, описанного в этой главе выше. Если установить этот атрибут равным false, не будут вызваны обработчики событий ни для Load, ни для Unload страницы Default (вы можете проверить это непосредственно, установив контрольные точки в пределах обработчиков событий Page_Load() и Page_Unload()).

Однако, если вы используете стандартный синтаксис событий C# для обработки событий Load и Unload, как показано ниже:

public partial class _Default: System.Web.UI.Page {

 public _Default() {

  // Явный перехват событий Load и Unload.

  this.Load += new EventHandler(Page_Load);

  this.Unload += new EventHandler(Page_Unload);

 }

 protected void Page_Load(object sender, EventArgs e) {

  Response.Write("Сработало событие Load!");

 }

 protected void Page_Unload(object sender, EventArgs e) {

  // Направить данные в HTTP-ответ здесь невозможно,

  // поэтому выполняется запись в локальный файл.

  System.IO.File.WriteAllText(@"C:\MyLog.txt", "Выгрузка страницы.");

 }

 protected void btnPostback_Click(object sender, EventArgs e) {

  // Здесь ничего не происходит, но это гарантирует

  // вторичный запрос к странице.

 }

}

то эти события будут перехвачены вашей страницей независимо от значения, заданного для AutoEventWireup.

В качестве заключительного замечания напомним, что с момента вызова события Unload вы не сможете взаимодействовать с подлежащим отправке HTTP-ответом (если вы попытаетесь вызвать члены объекта HttpResponse, среда выполнения сгенерирует соответствующее исключение). Поэтому здесь обработчик события Unload просто отправляет строку текста в файл на локальном диске C.

Еще одним событием, которое может происходить в цикле существования страницы, является событие Error, которое также работает в паре с делегатом System.EventHandler. Это событие возникает в том случае, когда метод производного от Page типа генерирует исключение, оставшееся без явной обработки. Предположим, что вы обработали событие Click для типа Button на странице, и в пределах обработчика события (здесь он называется btnGetFile_Click) вы пытаетесь записать, содержимое локального файла в HTTP-ответ.

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

public partial class _Default: System.Web.UI.Page {

 public _Default() {

 …

 // Создание объекта для события Error.

 this.Error += new EventHandler(_Default_Error);

 void _Default_Error(object sender, EventArgs е) {

  // Уничтожение текущего ответа, сообщение об сшибке

  // и информирование среды выполнения о том,

  // что ошибка обработана.

  Response.Clear();

  Response.Write("Извините… не могу найти необходимый файл.");

  Server.ClearError();

 }

 protected void btnGetFile_Click(object sender, EventArgs e) {

  // Попытка открыть несуществующий файл.

  // Это порождает событие Error для данной страницы.

  System.IO.File.ReadAllText(@"C:\IDontExist.txt");

 }

 …

}

Здесь обработчик события Error начинается с очистки всего содержимого имеющегося HTTP-ответа и вывода общего сообщения об ошибке. Чтобы получить доступ к конкретному объекту System.Exception, вы можете использовать метод HttpServerUtility.GetLastError(), доступ к которому обеспечивает унаследованное свойство Server.

void _Default_Error(object sender, EventArgs e) {

 Response.Clear();

 Response.Write("Извините… не могу найти необходимый файл. ‹br›");

 Response.Write(string.Format("Ошибка: ‹b›{0}‹/b›", Server.GetLastError().Message));

 Server.ClearError();

}

Наконец, отметьте, что перед выходом из этого общего обработчика ошибок с помощью свойства Server явно вызывается метод HttpServerUtility.ClearError(). Это необходимо, чтобы информировать среду выполнения о том, что проблема вами решена, и дальнейшего вмешательства системы не требуется. Если вы забудете сделать это, конечному пользователю будет предъявлено окно среды выполнения с сообщением об ошибке. На рис. 23.19 показан результат выполнения нашей процедуры обработки ошибок.

Рис. 23.19. Обработка ошибок на уровне страницы

В данный момент вы должны чувствовать себя довольно уверенно при работе с типом Page ASP.NET. Имея такую основу, вы теперь готовы перейти к выяснению роли Web-элементов управления ASP.NET.

Исходный код. Файлы примера PageLifeCycle размещены в подкаталоге, соответствующем главе 23.

Возможно, самым большим преимуществом ASP.NET является возможность компоновки пользовательского интерфейса страниц с помощью типов, определенных в пространстве имен System.Web.UI.WebControls. Соответствующие этим типам элементы управления (для которых могут использоваться названия серверные элементы управления, Web-элементы управления, или элементы управления Web-формы) оказываются чрезвычайно полезными в том, что они автоматически генерируют HTML-код, необходимый для запрашивающего браузера, и предлагают набор событий, которые может обработать Web-сервер, Каждому элементу управления ASP.NET соответствует класс из пространства имен System.Web.UI.WebControls, поэтому такой элемент управления может использоваться в рамках технологии ООП как в файле *.aspx (в блоке ‹script›), так и в файле внешнего кода поддержки.

Вы уже видели, что при настройке Web-элемента управления в окне свойств Visual Studio 2005 ваши изменения записываются в определение этого элемента в файле *.aspx в виде набора пар имен и значений. Например, при добавлении нового TextBox в окне проектирования файла *.aspx и изменении свойств BorderStyle, BorderWidth, BackColor, BorderColor и Text средствами IDE открывающий дескриптор ‹asp:TextBox› может измениться так, как показано ниже.

‹asp:TextBox id=myTextBox runat="server" BorderStyle="Ridge" BorderWidth="5px" BackColor="PaleGreen" BorderColor="DarkOliveGreen" Text = "Привет, Старик!"›

‹/asp:TextBox›

Поскольку HTML-декларация Web-элемента управления в конечном счете (в цикле динамический компиляции) становится членом-переменной из пространства имен System.Web.UI.WebControls, вы можете взаимодействовать с членами соответствующего типа в рамках блока ‹script› сервера или файла с внешним кодом поддержки страницы, например:

public partial class _Default: System.Web.UI.Page {

 …

 protected void btnChangeTextBoxColor_Click(object sender, EventArgs e) {

  // Изменение данных HTTP-ответа для данного элемента.

  this.myTextBox.BackColor = System.Drawing.Color.Red;

 }

}

Все Web-элементы управления ASP.NET восходят к общему базовому классу с именем Sуstem.Web.UI.WebControls.WebControl. Класс WebControl получается из System.Web.UI.Control (который, в свою очередь, получается из System.Objeсt). Классы Control и WebControl определяют свои наборы свойств, общие для всех серверных элементов управлений. Перед тем как рассмотреть наследуемые функциональные возможности элементов управления, давайте выясним, что формально означает обработка серверных событий.

С учетом сегодняшнего состояния World Wide Web нельзя не принимать во внимание природу взаимодействия браузера и Web-сервера. В основе такого взаимодействия лежит цикл запросов и ответов HTTP в процессе выполнения которых состояния не сохраняются. И хотя серверные элементы управления ASP.NET делают все возможное, чтобы избавить разработчика от необходимости непосредственного обращения к настройкам протокола HTTP, никогда не забывайте о том, что трактовка Web в терминах управления событиями – это великолепный "фокус" CLR, далеко не эквивалентный модели управления событиями пользовательского интерфейса Windows.

Поэтому, хотя пространства имен System.Windows.Forms и System.Web.UI.WebControls определяют типы с аналогичными именами (Button, TextBox, GridView, Label и т.д.), они предлагают разные наборы событий. Например, когда пользователь помещает указатель мыши на поверхность Button Web-формы, у вас нет возможности обработать событие MouseMove на стороне сервера. И это, очевидно, разумно. (Кто обрадуется перспективе посылать вторичные запросы серверу при каждом движении мыши?)

Поэтому Web-элементы управления ASP.NET предлагают ограниченные наборы событий, результатом которых, в конечном итоге, оказывается новое обращение к Web-серверу. Для обработки событий клиента вы должны создать соответствующие элементы программного кода сценария JavaScript/VBScript клиента, которые будут обрабатываться механизмом обслуживания сценариев соответствующего браузера.

Следует также подчеркнуть то, что многие Web-элементы управления ASP.NET поддерживают свойство AutoPostBack (это очень важно для CheckBox, RadioButton и TextBox, а также для элементов управления, получаемых из абстрактного типа ListControl). По умолчанию это свойство получает значение false (ложь), что означает отключение автоматической отправки серверных событий (даже при наличии соответствующей настройки в файле внешнего кода поддержки). Во многих случаях это оказывается именно тем, что требуется. Но если вы хотите, чтобы какой-то из элементов управления обращался к обработчику события на сервере, нужно установить для AutoPostBack значение true (истина). Это может оказаться полезным тогда, когда данные одного элемента управления должны автоматически становиться данными другого в пределах одной и той же страницы.

Для примера создайте Web-узел, содержащий один элемент управления TextBox (с именем txtAutoPostback) и один ListBox (с именем lstTextBoxData). Затем обработайте событие TextChanged элемента TextBox и в серверном обработчике события добавьте в ListBox текущее значение TextBox (уследили за идеей?).

protected void txtAutoPostback_TextChanged(object sender, EventArgs e) {

 lstTextBoxData.Items.Add(txtAutoPostback.Text);

}

Если выполнить приложение в таком виде, вы обнаружите, что в процессе ввода в TextBox ничего не происходит. Более того, ничего не произойдет и после ввода в TextBox при переходе к следующему элементу управления по нажатию клавиши табуляции. Причина в том, что свойство AutoPostBack типа TextBox по умолчанию имеет значение false. Но если установить для этого свойства значение true, как показано ниже:

‹asp:TextBox ID="txtAutoPostback" runat="server" AutoPostBack="True" OnTextChanged="txtAutoPostback_TextChanged"›

‹/asp:TextBox›

то вы увидите, что при выходе из TextBox по нажатию клавиши табуляции (или при нажатии клавиши ‹Enter›), ListBox автоматически получает текущее значение из TextBox. Без сомнения, кроме случая добавления данных одного элемента управления в другой, необходимости изменения состояния свойства AutoPostBack в других случаях не возникает.

Базовый класс System.Web.UI.Control определяет различные свойства, методы, и события, которые позволяют взаимодействовать с базовыми членами Web-элемента управления (обычно не относящимися к графическому интерфейсу). В табл. 23.9 предлагаются описания некоторых таких членов.

Таблица 23.5. Подборка членов System.Web.UI.Control

Первой из рассматриваемых здесь Особенностей System.Web.UI.Control является то, что все Web-элементы управления (это также относится и к Page) наследуют коллекцию пользовательских элементов управления (доступную с помощью свойства Controls). Во многом аналогично случаю приложений Windows Forms, в данном случае свойство Controls обеспечивает доступ к строго типизованной коллекции объектов WebControl. Подобно любой коллекции .NET, вы имеете возможность динамически добавлять и удалять элементы этой коллекции в среде выполнения.

Хотя добавлять Web-элементы управления в Page-тип можно и непосредственно, намного проще (и безопаснее) использовать для этого элемент управления Panel. Класс System.Web.UI.WebControls.Panel представляет контейнер элементов управления, который может быть видимым или невидимым для конечного пользователя (в зависимости от значений свойств Visible и BorderStyle).

Для примера создайте новый Web-узел с названием DynamicCtrls. В окне проектирования Web-страницы Visual Studio 2005 добавьте тип Panel (назначив ему имя myPanel), содержащий элементы TextBox, Button и HyperLink с произвольными именами (учтите, что режим проектирования требует, чтобы при перетаскивании внутренние элементы помещались в зону интерфейса типа Panel). В результате элемент ‹form› вашего файла *.aspx должен принять следующий вид.

‹asp:Panel ID="myPanel" runat="server" Height="50px" Width="125px"›

 ‹asp:TextBox ID="TextBox1" runat="server"›‹/asp:TextBox›‹br /›

 ‹asp:Button ID="Button1" runat="server" Text="Кнопка" /›‹br /›

 ‹asp:HyperLink ID="HyperLink1" runat="server"›Гиперссылка‹/asp:HyperLink›

‹/asp:Panel›

Затем разместите элемент Label (с названием lblControlInfo) вне контекста Panel, чтобы отображать соответствующий вывод. Учтите в Page_Load() то, что мы хотим получить список всех элементов управления, содержащихся в Panel, и присвоить полученные результаты типу Label.

public partial class _Default: System.Web.UI.Page {

 protected void Page_Load(object sender, EventArgs e) {

  ListControlsInPanel();

 }

 private void ListControlsInPanel() {

  string theInfo;

  theInfo = String.Format("Присутствие элементов: {0}‹br›", myPanel.HasControls());

  foreach (Control с in myPanel.Controls) {

   if (c.GetType() != typeof(System.Web.UI.LiteralControl)) {

    theInfo += "***************************‹br›";

    theInfo += String.Format("Name = {0}‹br›", с.ToString());

    theInfo += String.Format("ID = {0}‹br›", c.ID);

    theInfo += String.Format("Visible = {0}‹br›", c.Visible);

    theInfo += String.Format("ViewState = {0}‹br›", c.EnableViewState);

   }

  }

  lblControlInfo.Text = theInfo;

 }

}

Здесь выполняется цикл по всем типам WebControl, поддерживаемым в Panel, и осуществляется проверка того, что текущий тип не является типом System.Web.UI.LiteralControl. Этот тип используется для представления буквальных HTML-дескрипторов и содержимого (например, ‹br›, текстовых литералов и т.д.). Если вы не выполните такой проверки, вы с удивлением можете обнаружить в контексте Panel целых семь типов (для указанного выше определения *.aspx). В предположений о том, что тип не является буквальным HTML-содержимым, выводится определенная статистическая информация, Пример такого вывода показан на рис. 23.20.

Рис. 23.20. Перечень вложенных элементов

Но что делать, если нужно изменить содержимое Panel в среде выполнения? Соответствующий процесс должен показаться вам очень знакомым, если вы внимательно прочитали материал книги, посвященный работе с Windows Forms. Давайте добавим в текущую страницу кнопку (с названием btnAddWidgets), которая будет динамически добавлять в Panel пять новых типов TextBox, и еще одну кнопку, которая будет выполнять очистку Panel от всех элементов управления. Обработчики событий Click для этих кнопок приведены ниже.

protected void btnAddWidgets_Click(object sender, EventArgs e) {

 for (int i = 0; i ‹ 5; i++) {

  // Назначение имени, чтобы позже получить соответствующее

  // текстовое значение с помощью метода

  // HttpRequest.QueryString().

  TextBox t = new TextBox();

  t.ID = string.Format("newTextBox{0}", i);

  myPanel.Controls.Add(t);

  ListControlsInPanel();

 }

}

protected void btnRemovePanelItems_Click(object sender, EventArgs e) {

 myPanel.Controls.Clear();

 ListControlsInPanel();

}

Обратите внимание на то, что каждому TextBox назначается уникальное значение ID (newTextBox1, newTextBox2 и т.д.), чтобы можно было программными средствами получить содержащийся в этих элементах текст, используя коллекцию HttpRequest.Form (как будет показано чуть позже).

Чтобы получить значения этих динамически генерируемых типов TextBox, добавьте в пользовательский интерфейс еще один тип Button и тип Label. В пределах обработчика события Click для Button реализуйте цикл по всем элементам, содержащимся в рамках типа HttpRequest.NameValueCollection (доступного с помощью HttpRequest.Form), добавляя полученную текстовую информацию к локальному типу System.String. По завершении обработки коллекции назначьте эту строку свойству Text нового элемента Label с именем lblTextBoxText.

protected void btnGetTextBoxValues_Click(object sender, System.EventArgs e) {

 string textBoxValues = "";

 for(int i = 0; i ‹ Request.Form.Count; i++) {

  textBoxValues += string.Format("‹li›{0}‹/li›‹br›", Request.Form[i]);

 }

 lblTextBoxText.Text = textBoxValues;

}

Запустив приложение, вы сможете увидеть как содержимое текстовых блоков, так и довольно длинные ("нечитаемые") строки. Такие строки отражают визуальное состояние элементов на странице и будут рассматриваться позже, в следующей главе. Также вы заметите, что после обработки запроса новые текстовые окна исчезают. Причина опять кроется в природе HTTP – этот протокол не обеспечивает сохранения состояния. Чтобы динамически созданные типы TextBox сохранялись после вторичных запросов, вы должны сохранить состояния этих объектов, используя соответствующие приемы программирования ASP.NET (эти вопросы также рассматриваются в следующей главе).

Исходный код. Файлы примера DynamicCtrls размещены в подкаталоге, соответствующем главе 23.

Можно сказать, что тип Control предлагает возможности поведения, не относящиеся к графическому интерфейсу. С другой стороны, базовый класс WebControl обеспечивает полиморфный графический интерфейс для всех Web-элементов поведения, как показано в табл. 23.10.

Таблица 23.10. Свойства базового класса WebControl

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

Типы в System.Web.UI.WebControls можно разбить на несколько больших категорий.

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

• Элементы управления с расширенными возможностями

• Элементы управления для работы с источниками данных

• Элементы управления для контроля ввода

• Элементы управления для входа в систему

Простые элементы управления называются так потому, что они являются Web-элементами управления ASP.NET, отображающимися в стандартные HTML-элементы (кнопки, списки, гиперссылки, контейнеры изображений, таблицы и т.д.). Далее мы имеем небольшое множество так называемых элементов управления с расширенными возможностями, для которых нет прямого эквивалента среди HTML-элементов (это, например, Calendar, TreeView, wizard и т.д.). Элементы управления для работы с источниками данных являются элементами, для заполнения которых обычно требуется соединение с источником данных. Лучшим (и наиболее интересным) примером такого элемента управления ASP.NET является, наверное, GridView. Другими членами этой категории являются так называемый "ротатор" и элемент управления DataList. Элементы управления для контроля ввода являются серверными элементами управления, автоматически генерирующими JavaScript-код клиента для проверки вводимых в форму данных. Наконец, библиотеки базовых классов ASP.NET 2.0 предлагают целый ряд элементов управления, связанных с решением проблем безопасности, Эти элементы интерфейса инкапсулируют все особенности регистрации доступа к узлу, предлагая, в частности, сервис ввода и получения пароля и поддержку ролей пользователей.

Замечание. Поскольку в этой книге не предлагается обсуждение системы безопасности .NET, здесь не будут обсуждаться и соответствующие новые элементы управления. Если вам потребуется подробная информация по проблемам безопасности ASP.NET 2.0, обратитесь к книге Dominic Selly, Andrew Troelsen and Tom Barnaby, Expert ASP.NET 2.0 Advanced Application Design (Apress, 2006).

Вообще говоря, есть два разных набора Web-элементов управления, предлагаемых в рамках дистрибутива .NET 2.0. В дополнение к Web-элементам управления ASP.NET (из пространства имен System.Web.UI.WebControls), библиотеки базовых классов предлагают также элементы System.Web.UI.HtmlControls.

HTML-элементы управления представляют собой коллекцию типов, позволяющих использовать традиционные элементы управления HTML на странице Web-формы. Однако, в отличие от стандартных HTML-дескрипторов, HTML-элементы управления являются сущностями ООП, которые могут быть настроены для выполнения на сервере и поэтому поддерживают серверную обработку событий. В отличие от Web-элементов управления ASP.NET, HTML-элементы управления по своей природе очень просты и имеют не слишком широкие возможности, аналогичные стандартным дескрипторам HTML (HtmlButton, HtmlInputControl, HtmlTable и т.д.).

HTML-элементы управления предлагают открытый интерфейс, "имитирующий" стандартные HTML-атрибуты. Например, чтобы получить информацию из области ввода, вы должны использовать свойство Value, а не свойство Text, как в случае Web-элементов. Поскольку HTML-элементы управления обладают не такими богатыми возможностями, как Web-элементы управления ASP.NET, далее в этой книге HTML-элементы управления упоминаться не будут. Если вы захотите изучить эти типы, обратитесь к документации .NET Framework 2.0 SDK.

Ограниченный объем книги не позволяет здесь описать особенности всех Web-элементов управления, входящих в доставку ASP.NET 2.0 (для этого требуется отдельная и довольно объемная книга). Но чтобы проиллюстрировать работу с paзличными Web-элементами управления ASP.NET, следующим нашим заданием в этой главе будет создание Web-узла, демонстрирующего использование следующих возможностей.

• Работа с шаблонами страниц

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

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

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

При работе с примером не забывайте о том, что элементы управления Web-формы инкапсулируют возможности генерирования соответствующих HTML-дескрипторов и следуют модели Windows Forms. Для начала создайте новое Web-приложение ASP.NET с названием AspNetCarSite.

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

Упрощенно говоря, шаблон страницы отличается от обычной страницы ASP.NET почти исключительно только тем, что он размещается в файле *.master. Сами по себе шаблоны страниц не являются видимыми для браузера клиента (фактически среда выполнения ASP.NET не обслуживает эту часть Web-содержимого). Шаблоны страниц определяют общий каркас пользовательского интерфейса, совместно используемый всеми страницами (или подмножеством страниц) узла. Кроме того, страница *.master определяет различные дескрипторы-заполнители, получающие дополнительное содержимое в файле *.aspx. В результате получается общий, унифицированный пользовательский интерфейс.

Добавьте в свой Web-узел новый шаблон страницы (выбрав Web Site>Add New Item из меню) и рассмотрите его исходное определение.

‹%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %›

‹!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/ TR/xhtml11/DTD/xhtml11.dtd"›

‹html xmlns="http://www.w3.org/1999/xhtml"›

 ‹head runat="server"›

  ‹title›Untitled Page‹/title›

 ‹/head›

 ‹body›

  ‹form id="form1" runat="server"›

   ‹div›

    ‹asp:contentplaceholder id="ContentPlaceHolder1" runat="server"›

    ‹/asp:contentplaceholder›

   ‹/div›

  ‹/form›

 ‹/body›

‹/html›

Первым интересным элементом здесь является новая директива ‹%@Master%›. По большей части эта директива поддерживает те же атрибуты, что и ‹%@Page%›. Например, обратите внимание на то, что по умолчанию шаблон страницы предполагает использование файла внешнего кода поддержки (который, строго говоря, не обязателен). Подобно типам Page, шаблоны страниц получаются из специального базового класса, которым в данном случае является MasterPage.

public partial class MasterPage: System.Web.UI.MasterPage {

 protected void Page_Load(object sender, EventArgs e) {

 }

}

Важно знать о том, что атрибуты, определенные директивой ‹%@Master%›, не "перетекают" в связанные файлы *.aspx. Поэтому вы можете, например, использовать C# в рамках шаблона страниц, а для связанного файла *.aspx использовать Visual Basic .NET.

Другим интересным элементом является ‹asp:contentplaceholder›. Эта область шаблона представляет элемент пользовательского интерфейса в связанном файле *.aspx, а не содержимое самого шаблона страниц. Если обработать файл *.aspx в рамках этой части шаблона, то контекст дескрипторов ‹asp:contentplaceholder› и ‹/asp:contentplaceholder› окажется пустым. Однако при желании вы можете наполнить эту область различными Web-элементами управления, которые будут функционировать в качестве элементов пользовательского интерфейса, используемых по умолчанию в том случае, когда данный файл *.aspx узла не предложит свое конкретное содержимое. Для этого примера мы предполагаем, что все страницы *.aspx узла предоставляют подходящее пользовательское содержимое.

Замечание. Страница *.master может определять столько заместителей содержимого, сколько необходимо. Также страница *.master может содержать дополнительные вложенные страницы *. master.

Как и следует ожидать, в Visual Studio 2005 имеется возможность построить общий интерфейс файла *.master с помощью тех же инструментов проектирования, что и в случае построения файлов *.aspx. Для своего узла добавьте информирующую надпись Label (чтобы использовать ее для общего приветственного сообщения), элемент управления AdRotator (который будет случайным образом отображать одно из двух изображений) и элемент управлений Menu (чтобы позволить пользователю перейти к другим частим узла).

ASP.NET 2.0 предлагает несколько новых Web-элементов управления, которые позволяют реализовать возможности навигации в пределах узла. Это SiteMapPath, TreeView и Menu. Как вы можете догадаться, эти Web-элементы могут быть настроены множеством способов. Например, каждый из этих элементов управления мо-Ш&т динамически генерировать, свои строки с помощью внешнего XML-файла или источник данных, Но для нашего типа Menu мы просто укажем три значения непосредственно.

В режиме проектирования Web-страницы, выберите элемент управления Menu, активизируйте встроенный редактор этого элемента (используй маркер в верхнем углу элемента) и выберите Edit Menu Items. Добавьте три корневых элемента Начало обзора, Создать машину и Ассортимент. Перед закрытием диалогового окна установите для свойства NavigateUrl каждого элемента ссылки на следующие страницы (которые еще не созданы).

• Начало обзора: Default.aspx

• Создать машину: BuildCar.aspx

• Ассортимент: Inventory.aspx

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

Роль элемента AdRotator ASP.NET заключается в случайном отображении изображений в некоторой позиции в окне браузера. Непосредственно после размещения AdRotator в окне проектирования он отображается в виде пустого заместителя элемента. Функционально этот элемент управления не сможет выполнять свою задачу до тех пор, пока вы не назначите свойству AdvertisementFile ссылку на файл, описывающий все изображения. Для нашего примера источником данных будет простой XML-файл с именем Ads.Xml.

Добавив этот новый XML-файл в узел, укажите в нем уникальный элемент ‹Ad› для каждого изображения, которое требуется отобразить. Как минимум, каждый элемент ‹Ad› должен указать изображение для отображения (ImageUrl), адрес URL для перехода при выборе данного изображения (TargetUrl), текст, появляющийся при размещении указателя мыши на изображении (AlternateText) и "вес" изображения (Impressions).

‹Advertisеments›

 <Ad>

  ‹ImageUrl›SlugBug.jpg‹/ImageUrl›

  ‹TargetUrl›http://www.Cars.com‹/TargetUrl›

  ‹AlternateText›Ваша новая машина?‹/AlternateText›

  ‹Impressions›80‹/Impressiоns›

 ‹/Ad›

 ‹Ad›

  ‹ImageUrl›car.gif‹/ImageUrl›

  ‹TargetUrl›http://www.CarSuperSite.com‹/TargetUrl›

  ‹AlternateText›Нравится эта машина?‹/AlternateText›

  ‹Impressions›80‹/Impressions›

 ‹/Ad›

‹/Advertisements›

Теперь можно связать XML-файл с элементом управления AdRotator с помощью свойства AdvertisementFile (в окне свойств).

‹asp:AdRotator ID="myAdRotator" runat="server" AdvertisementFile="~/Ads.xml"/›

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

Рис. 23.21. Шаблон страницы

После установки шаблона страниц вы можете приступить к созданию индивидуальных страниц *.aspx, определяющих в совокупности с дескриптором ‹asp: contentplaceholder› шаблона содержимое пользовательского интерфейса. При создании нового Web-узла среда разработки Visual Studio 2005 автоматически создает начальный файл *.aspx, но в исходном своем состоянии этот файл не может быть соединен с шаблоном страниц.

Причина в том, что именно файл *.master определяет раздел ‹form› результирующей HTML-страницы. Поэтому существующую область ‹form› в файле *. aspx нужно заменить на ‹asp:content›. Переключитесь в режим Source дли Default.aspx и замените имеющуюся разметку следующей.

‹%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %›

‹asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server"›

‹/asp:Content›

Прежде всего обратите внимание на то, что директива ‹%Page%› здесь получает новый атрибут MasterPageFile, которому присвоено значение вашего файла *.master. Также отметьте, что значение ContentPlaceHolderID идентично значению элемента ‹asp:contentplaceholder› из файла шаблона.

После переключения обратно в режим проектирования (режим Design) вы обнаружите, что пользовательский интерфейс шаблона страницы стал видимым. Область содержимого также видима, хотя в данный момент она пуста. У нас нет необходимости строить сложный интерфейс для области содержимого Default.aspx. поэтому для примера просто добавьте несколько типов Label, чтобы отобразить основные инструкции узла (рис. 23.22).

Рис. 23.22. Страница содержимого Default.aspx

Если теперь запустить проект на выполнение то вы увидите, что содержимое интерфейсов файлов *.master и Default.aspx сливается в едином HTML-потоке. Как видно из рис. 23.23, конечный пользователь не увидит даже признаков того, что существует шаблон страницы.

Рис. 23.23. Страница Cars R Us, открываемая по умолчанию

Чтобы добавить в проект страницу содержимого Inventory.aspx, откройте в среде разработки страницу *.master и выберите WebSite>Add Content Page из меню (если файл *.master не является активным элементом, этот пункт меню не предлагается). Роль страницы Inventory заключается в отображении содержимого таблицы Inventory базы данных Cars в рамках элемента управления GridView.

Вы, наверное, знаете, что элемент управления GridView не ограничивается представлением данных только для чтения. Этот элемент можно настроить так, чтобы поддерживались сортировка, перелистывание и редактирование данных. При желании вы имеете возможность выполнить серверную обработку серии событий, добавив соответствующий программный код ADO.NET. Этот элемент ASP.NET 2.0 заменяет соответствующий элемент ASP.NET 1.x c его "менталитетом нулевого программного кода.

С помощью нескольких щелчков кнопки мыши вы можете настроить GridView на автоматический выбор, обновление и удаление записей соответствующего хранилища данных. "Нулевой" программный код сильно уменьшает объем вводимого шаблонного программного кода, но важно понимать, что эта простота сопровождается потерей контроля и не может быть рекомендована для использования в приложениях производственного уровня.

Тем не менее, для иллюстрации возможностей использования GridView в этой декларативной форме добавьте новую страницу (Inventory.aspx) и создайте в области содержимого информирующий тип Label и тип GridView. Используя встроенный редактор, выберите New Data Source из раскрывающегося списка Choose Data Source. Будет запущен мастер, который за несколько шагов поможет вам соединить компонент с соответствующим источником данных. Вот шаги, которые нужно сделать для нашего примера.

1. Выберите пиктограмму Database и укажите CarsDataSource для идентификатора источника данных.

2. Выберите базу данных Cars (если потребуется, создайте для этого новое соединение).

3. Если хотите, сохраните данные строки соединений в файле Web.config. Напоминаем (см. главу 22), что ADO.NET теперь поддерживает элемент ‹connectionStrings›.

4. Укажите SQL-оператор Select для выбора всех записей из таблицы Inventory (pиc. 23.24).

Рис. 23.24. Выбор таблицы Inventory

Если теперь проверить содержимое открывающего дескриптора элемента управления GridView, вы увидите, что свойство DataSourceID получило тот тип SqlDataSource, который вы только что определили.

‹asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False" CellPadding="4" DataKeyNames="CarID" DataSourceID="CarsDataSource" ForeColor="#33333З" GridLines="None"›

…

‹/asp:GridView›

Тип SqlDataSource (новый в .NET 2.0) - это компонент, инкапсулирующий информацию о хранилище данных. С учетом знаний, освоенных вами в главе 22, следующие атрибуты должны быть для вас понятными:

‹asp:SqlDataSource ID="CarsDataSource" runat="server" ConnectionString="Data Source=localhost;Initial Catalog=Cars;Integrated Security=True" ProviderName=''System.Data.SqlClient" SelectCommand="SELECT * FROM [Inventory]"›

‹/asp:SqlDataSource›

Теперь вы можете запустить свою Web-программу, выполнить щелчок на пункте меню Ассортимент и просмотреть соответствующие данные (рис. 23.25).

Рис. 23.25. Элемент управления GridView без дополнительного программного кода

Элемент управления GridView можно легко настроить для сортировки (по ссылке на имя столбца] и перелистывания страниц (по номеру или гиперссылке на следующую/предыдущую страницу). Для этого нужно активизировать встроенный редактор элемента и отметить соответствующие пункты меню (рис. 23.26).

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

Рис. 23.26. Разрешение перелистывания и сортировки страниц

Заключительным штрихом оформления этой страницы будет поддержка элементом управления GridView редактирования данных. Для этого откройте встроенный редактор для SqlDataSource и выберите Configure Data Source. Пропустите первые два окна этого мастера, а на шаге 3 щелкните на кнопке Advanced и отметьте первый вариант настройки (рис. 23.27).

Рис. 23.27. Автоматическое генерирование SQL-операторов

Если теперь рассмотреть HTML-определение элемента управления, то вы увидите, что для SqlDataSource определены DeleteCommand, InsertCommand и UpdateCommand (с помощью параметризованных запросов).

‹asp:SqlDataSource ID="CarsDataSource" runat="server" ConnectionString="Data Source=localhost;Initial Catalog=Cars;Integrated Security=True"  ProviderName="System.Data.SqlClient" SelectCommand="SELECT * FROM [Inventory]" DeleteCommand="DELETE FROM [Inventory] WHERE [CarID] = @original_CarID" InsertCommand="INSERT INTO [inventory] ([CarID], [Make], [Color], [PetName]) VALUES (@CarID, @Make, @Color, @PetName)" UpdateCommand="UPDATE [Inventory] SET [Make] = @Make, [Color] = @Color, [PetName]=@PetName WHERE [CarID]=@original_CarID"›

…

‹/asp:SqlDataSource›

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

‹DeleteParameters›

 ‹asp:Parameter Name="original_CarID" Type="Int32" /›

‹/DeleteParameters›

‹UpdateParameters›

 ‹asp:Parameter Name="Make" Type="String" /›

 ‹asp:Parameter Name="Color" Type="String" /›

 ‹asp:Parameter Name="PetName" Type="String" /›

 ‹asp:Parameter Name="original_CarID" Type="Int32" /›

‹/UpdateParameters›

‹InsertParameters›

 ‹asp:Parameter Name="CarID" Type="Int32" /›

 ‹asp:Parameter Name="Make" Type="String" /›

 ‹asp:Parameter Name="Color" Type="String" /›

 ‹asp:Parameter Name="PetName" Type="String" /›

‹/InsertParameters›

Заключительным шагом является разрешение поддержки редактирования и удаления данных с помощью встроенного редактора GridView (рис. 23.28).

Рис. 23.28. Разрешение поддержки редактирования и удаления данных

Достаточно очевидно, что при новом обращении к странице Inventorу.aspx вы сможете редактировать и удалять записи (рис. 23.29).

Рис. 23.29. Таблица всех таблиц

Последним нашим заданием в этом примере будет создание страницы BuildCar.aspx. Добавьте ее в свой проект (выбрав Web Site>Add Content Page из меню). Эта страница будет содержать Web-элемент управления Wizard ASP.NET 2.0, который обеспечит простой способ прохождения конечного пользователя через серию связанных шагов. Здесь соответствующие шаги будут имитировать выбор покупателем автомобили с нужными ему характеристиками.

Поместите в область содержимого информирующую надпись и элемент управления Wizard. Затем активизируйте встроенный редактор для Wizard и щелкните на ссылке Add/Remove WizardSteps (Добавить или удалить шаги мастера). Добавьте четыре шага, как показано на рис. 23.30.

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

Рис. 23.30. Конфигурация шагов Wizard

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

• Выберите модель: элемент управления TextBox

• Выберите цвет: элемент управления ListBox

• Укажите название: элемент управления TextBox

• Укажите дату доставки: элемент управления Calendar

Элемент управления ListBox является единственным элементом интерфейса Wizard, требующим дополнительной настройки. Выберите этот элемент в окне проектирования (убедившись, что перед этим вы выбрали ссылку Выберите цвет) и укажите для элемента набор цветов с помощью свойства Items в окне свойств. После этого в контексте определения Wizard вы обнаружите разметку, похожую на следующую.

‹asp:ListBox ID="ListBoxColors" runat="server" Width="237px"›

 ‹asp:ListItem›пурпурный‹/asp:ListItem›

 ‹asp:ListItem›зеленый‹/asp:ListItem›

 ‹asp:ListItem›красный‹/asp:ListItem›

 ‹asp:ListItem›желтый‹/asp:ListItem›

 ‹asp:ListItem›светло-зеленый‹/asp:ListItem›

 ‹asp:ListItem›черный‹/asp:ListItem›

 ‹asp:ListItem›лимонный‹/asp:ListItem›

‹/asp:ListBox›

После определения каждого из шагов вы можете обработать событие FinishButtonClick для автоматически генерируемой кнопки Finish (Готово). В серверном обработчике события получите параметры выделения от каждого элемента интерфейса и постройте строку описания, которая будет назначена свойству Text дополнительного типа Label с именем lblOrder.

protected void carWizard_FinishButtonClick(object sender, WizardNavigationEventArgs e) {

 // Получение значений.

 string order = string.Format("{0}, ваш {1} {2}, будет доставлен {3}.",

  txt.CarPetName.Text,

  ListBoxColors.SelectedValue,

  txtCarModel.Text,

  carCaLendar.SelectedDate.ToShortDateString());

 // Присваивание значения надписи.

 lblOrder.Text = order;

}

Итак, ваш узел AspNetCarSite готов. На рис. 23.31 показан элемент Wizard в действии.

Рис. 23.31. Wizard в действии

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

Исходный код. Файлы AspNetCarsSite размещены в подкаталоге, соответствующем главе 23.

Заключительной группой рассматриваемых здесь элементов управления Web-формы являются так называемые элементы контроля ввода. В отличие от остальных рассмотренных нами элементов управления Web-формы, элементы контроля ввода используются для генерирования не HTML-кода, а JavaScript-кода клиента (и, возможно, программного кода сервера), предназначенного для проверки правильности вводимых в форму данных. Как показано в начале этой главы, контроль ввода на стороне клиента полезен тем, что в этом случае вы можете обеспечить выполнение различных ограничений для вводимых данных на месте, перед тем как возвратить данные Web-серверу, в результате чего число ресурсоемких обращений к серверу уменьшается. В табл. 23.11 предлагаются описания элементов управления ASP.NET, связанных с контролем ввода.

Таблица 23.11. Элементы контроля ввода ASP.NET

Все элементы контроля ввода, в конечном счете, получаются из общего базового класса System.Web.UI.WebControls.BaseValidator, поэтому они должны иметь множество общих свойств. Описания ряда таких свойств предлагаются в табл. 23.12.

Чтобы продемонстрировать основы работы с элементами контроля ввода, создайте новый Web-узел с именем ValidatorCtrls. Сначала поместите на страницу четыре типа TextBox (с четырьмя соответствующими информирующими типами Label). Затем по соседству с каждым полем разместите типы RequiredFieldValidator, RangeValidator, RegularExpressionValidator и CompareValidator. Наконец, добавьте одну кнопку (Button) и надпись (Label), рис. 23.32.

Таблица 23.12. Общие свойства элементов контроля ввода ASP.NET

Рис. 23.32. Элементы, которые придется контролировать

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

Настроить RequiredFieldValidator очень просто. В окне свойств Visual Studio 2005 установите для свойств ErrorMessage и ControlToValidate нужные значения. Определение *.aspx должно быть таким.

‹asp:RequiredFieldValidator ID="RequiredFieldValidator1" runat="server" ControlToValidate="txtRequiredField" ErrorMessage="Ой! Здесь нужно ввести данные. "›

‹/asp:RequiredFieldValidator›

Одной приятной особенностью RequiredFieldValidator является то, что этот элемент поддерживает свойство InitialValue. Это свойство используется для того, чтобы гарантировать ввод пользователем любого значения, отличного от начального значения соответствующего поля TextBox. Например, если пользователь обращается к странице впервые, вы можете настроить TextBox на отображение значения "Введите свое имя". Если не установить свойство InitialValue элемента RequiredFieldValidator, среда выполнения будет предполагать, что строка "Введите свое имя" является действительной, Для гарантии того, что данный TextBox пройдет контроль только тогда, когда пользователь введет строку, отличную от "Введите свое имя", вы должны настроить элемент так, как показано ниже.

‹asp:RequiredFieldValidator ID="RequiredFieldValidator1" гunat="server" ControlToValidate="txtRequiredField" ErrorMessage="Ой! Здесь нужно ввести данные." InitialValue="Введите свое имя"›

‹/asp:RequiredFieldValidator›

Элемент RegularExpressionValidator

Элемент RegularExpressionValidator может использоваться тогда, когда требуется сравнение введенных символов с некоторым шаблоном. Так, для гарантии того, что поле данного TextBox содержит действительный номер социальной страховки США (US SSN), можно определить элемент так, как предлагается ниже.

‹asp:RegularExpressionValidator ID="RegularExpressionValidator1" runat="server" ControlToValidate="txtRegExp" ErrorMessage="Введите действительное значение US SSN." ValidationExpression="\d{3}-\d{2}-\d{4}"›

‹/asp:RegularExpressionValidator›

Здесь обратите внимание на то, что RegularExpressionValidator определяет свойство ValidationExpression. Если вы никогда не работали с регулярными выражениями, вам для понимания этого примера нужно знать только то, что регулярные выражения используются для проверки соответствия заданному строковому шаблону. Указанное здесь выражение "\d{3}-\d{2}-\d{4}" соответствует стандартному номеру социальной страховки в США, имеющему вид ххх-хх-хххх (где x означает любую цифру).

Это конкретное регулярное выражение вполне очевидно, но предположим, что нам нужно проверить соответствие действительному телефонному номеру Японии. Выражение, необходимое в данном случае, является более сложным – оно имеет вид "(0\d{1,4}-|\(0\d{1,4}\)?)?\d{1,4}-\d{4}". Поэтому очень хорошо, что при выборе свойства ValidationExpression в окне свойств вы имеете возможность выбрать подходящее значение из встроенного набора часто используемых регулярных выражений (рис. 23.33).

Замечание. Если вам действительно нужны регулярные выражения, то знайте, что платформа .NET для программной работы с регулярными выражениями предлагает два пространства имен (System.Text.RegularExpressions и Systern.Web.RegularExpressions).

Рис. 23.33. Создание регулярного выражения с помощью Visual Studio 2005

В дополнение к Свойствам MinimumValue и MaximumValue, элементы RangeValidator имеют свойство Type. Чтобы выполнить проверку ввода пользователя на соответствие заданному диапазону целых чисел, для этого свойства нужно указать Integer (что не является значением по умолчанию!).

‹asp:RangeValidator ID="RangeValidator1" runat="server" ControlToValidate="txtRange" ErrorMessage="Введите значение между 0 и 100." MaximumValue="100" MinimumValue="0" Type="Integer"›

‹/asp:RangeValidator›

Элемент RangeValidator можно использовать и тогда, когда нужно проверить, что введенное значение принадлежит заданному диапазону денежных значений, значений дат, чисел с плавающей точкой или строковых данных (это и есть значение, устанавливаемое по умолчанию).

Наконец, обратим ваше внимание на то, что CompareValidator поддерживает свойство Operator.

‹asp:CompareValidator ID="CompareValidator1" runat="server" ControlToValidate="txtComparison" ErrorMessage="Введите значение, меньшее 20." Operator="LessThan" ValueToCompare="20"›

‹/asp:CompareValidaror›

Поскольку задачей этого элемента контроля ввода является сравнение значения в текстовом блоке с другим значением при помощи бинарного оператора, не удивительно то, что свойству Operator можно назначить такие значения, как LessThan (меньше), GreaterThan (больше), Equal (равно) и NotEqual (не равно). Также заметьте, что для указания значения, с которым производится сравнение, используется ValueToCompare.

Замечание. С помощью свойства ControlToValidate элемент CompareValidator можно настроить на сравнение со значением из другого элемента управления Web-формы (а не с конкретным "жестко" заданным значением).

Чтобы завершить создание программного кода для страницы, обработайте событие Click для типа Button и проинформируйте пользователя о завершении работы программы контроля.

protected void btnPostback_Cliсk(object sender, EventArgs e) {

 lblValidationComplete.Text = "Вы прошли контрольную проверку!";

}

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

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

В связи со всем сказанным, если HTTP-запрос был послан браузером, не поддерживающим JavaScript клиента, весь контроль будет происходить на сервере. Поэтому вы можете программировать элементы контроля ввода без учета возможностей целевого браузера – возвращенная HTML-страница направит задачу контроля ошибок обратно Web-серверу.

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

Первым шагом при этом является добавление ValidationSummary в файл *.aspx. Дополнительно можно установить свойство HeaderText этого типа, а также значение DisplayMode, которое по умолчанию задает представление сообщений об ошибках в виде списка с буллитами.

‹asp:ValidationSummary id="ValidationSummary1" style="Z-INDEX: 123; LEFT: 152px; POSITION: absolute; TOP: 320px" runat="server" Width="353px" HeaderText="Элементы ввода, требующие корректировки."›

‹/asp:ValidationSummary›

Затем для каждого элемента контроля ввода на странице (для RequiredFieldValidator, RangeValidator и т.д.) нужно установить свойство Display равным значению None. Это гарантирует, что вы не увидите дубликатов сообщений об ошибках для одного и того же случая неудачного завершения проверки (когда одно сообщение отображается в резюмирующем списке, а другое – в месте размещения элемента контроля ввода).

Наконец, если требуется отобразить сообщения об ошибке с помощью MessageBox клиента, то установите для свойства ShowMessageBox значение true (истина), а для свойства ShowSummary – значение false (ложь).

Исходный код. Проект ValidatorCtrls размещен в подкаталоге, соответствующем главе 23.

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

Значительная часть главы была посвящена рассмотрению архитектуры страницы ASP.NET. Вы увидели, что с каждым файлом *.aspx в проекте связан некоторый класс, производный от System.Web.UI.Page. С помощью такого подхода ASP.NET позволяет строить более пригодные для многократного использования системы, соответствующие принципам ООП. В этой главе рассматривалась также использование шаблонов страниц и различных Web-элементов управления (включая новые типы GridView и Wizard). Вы могли убедиться в том, что эти элементы графического интерфейса отвечают за создание подходящих дескрипторов HTML-кода, направляемого клиенту. Элементы контроля ввода являются серверными элементами, на которые возлагается задача подготовки JavaScript-кода клиента для выполнения проверки допустимости введенных в форму данных, чтобы уменьшить количество необходимых обращений к серверу.

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

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

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

public partial class MainWindow: Form {

 // Данные состояния.

 private string userFavoriteCar;

 …

}

Однако в World Wide Web вы не можете делать такие роскошные предположения. Чтобы не быть голословными, давайте создадим новый Web-узел ASP.NET (с именем SimpleStateExample), содержащий один файл *.aspx. В файле с внешним кодом поддержки определим строковую переменную уровня страницы с именем userFavoriteCar.

public partial class _Default: Page {

 // Данные состояния?

 private string userFavoriteCar;

}

Далее, построим Web-интерфейс пользователя, показанный на рис. 24.1.

Рис. 24.1. Пользовательский интерфейс для страницы примера состояния

Обработчик события Click сервера для кнопки Указать… позволит назначить строковую переменную в соответствии со значением TextBox:

protected void btnSetCar_Click(object sender, EventArgs e) {

 // Сохранение информации о машине.

 userFavoriteCar = txtFavCar.Text;

}

а обработчик события Click для кнопки Прочитать… будет отображать текущее значение члена-переменной в поле элемента Label страницы.

protected void btnGetCar_Click(object sender, EventArgs e)

 // Присваивание тексту надписи значения члена-переменной.

 lblFavCar.Text = userFavoriteCar;

}

При построении приложения Windows Forms можно предполагать, что после установки пользователем начального значения это значение будет сохраняться в течение всего времени работы приложения. Запустив наше Web-приложение, вы, к сожалению, обнаружите, что при каждом вторичном обращении к Web-серверу значение строковой переменной userFavoriteCar снова возвращается в своему пустому начальному значению, так что поле текста Label будет постоянно оставаться пустым.

Снова подчеркнем, что HTTP не имеет никаких внутренних средств автоматического запоминания данных уже отправленного HTTP-ответа, и именно поэтому объект Page немедленно уничтожается. Когда клиент повторно обращается к файлу *.aspx, создается новый объект Page, переустанавливающий все члены-переменные уровня страницы. Это, очевидно, и оказывается главной проблемой. Представьте себе, каким бы неудобным был процесс заказа товаров, если бы каждый раз при обращении к Web-серверу вся введенная вами информация (например, о том, что вы хотите купить) пропадала. Если вам необходимо помнить информацию о пользователях, которые регистрируются на вашем узле, вам придется использовать различные приемы сохранения состояния объектов.

Замечание. Эта проблема касается не только ASP.NET. Сервлеты Java, CGI-, "классические" ASP-и РНР-приложения – всем этим технологиям также приходится решать проблемы управления состоянием.

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

protected void btnSetCar_Click(object sender, EventArgs e) {

 Session["UserFavCar"] = txtFavcar.Text;

}

protected void btnGetCar_Click(object sender, EventArgs e) {

 lblFavCar.Text = (string)Session["UserFavCar"];

}

Если выполнить приложение теперь, то информация о любимой машине в промежутке между обращениями к серверу будет сохраняться благодаря объекту HttpSessionState, обрабатываемому с помощью унаследованного свойства

Исходный код. Файлы примера SimpleStateExample размещены в подкаталоге, соответствующем главе 24.

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

• Использование данных состояния представлений ASP.NET.

• Использование данных состояния элементов управления ASP.NET.

• Определение переменных уровня приложения.

• Использование объектов кэширования.

• Определение переменных сеансового уровня.

• Взаимодействие с данными cookie.

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

Термин состояние представлений уже упоминался множество раз здесь и в предыдущей главе без формального определения, так что позвольте демистифицировать этот термин раз и навсегда. В рамках классической технологии ASP требовалось, чтобы Web-разработчики вручную указывали значения элементов формы в процессе построения исходящего HTTP-ответа, Например, если поступивший HTTP-запрос содержал пять текстовых блоков с конкретными значениями, файл *.asp должен был извлечь текущие значения (с помощью коллекций Form или QueryString объекта Request) и вручную поместить их в поток HTTP-ответа (ясно, что это было весьма неудобное решение). Если разработчик этого не делал, то пользователь видел пять пустых текстовых блоков.

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

Обработчик события Init базового класса System.Web.UI.Page отвечает за чтение значений, обнаруженных в поле __VIEWSTATE, и заполнение соответствующих членов-переменных в производном классе (именно поэтому по крайней мере рискованно использовать доступ к параметрам состояния Web-элемента в контексте обработчика события Init страницы).

Точно так же перед исходящим ответом браузеру данные __VIEWSTATE используется для заполнения элементов формы, чтобы текущие значения HTML-элементов оставались такими же, какими они были до повторного обращения к серверу.

Очевидно, лучшим аспектом поведения ASP.NET в этом отношении является то, что все это происходит без вашего вмешательства. При этом, при желании, вы можете изменить или отключить такое принятое по умолчанию поведение. Чтобы понять, как это сделать, давайте рассмотрим конкретный пример использования данных состояния представлений.

Создайте новое Web-приложение ASP.NET с названием ViewStateApp. В исходную страницу *.aspx добавьте один Web-элемент управления ASP.NET ListBox и один тип Button. Обработайте событие Click для Button, чтобы обеспечить пользователю возможность вторичного обращения к Web-серверу.

protected void btnDoPostBack_Click(object sender, EventArgs e) {

 // Для вторичного обращения к серверу.

}

Теперь, используя окно свойств Visual Studio 2005, получите доступ к свойству Items и добавьте в ListBox четыре элемента ListItem. Результат должен быть примерно таким.

‹asp:ListBox ID="myListBox" runat="server"›

 ‹asp:ListItem›Элемент 1‹/asp:ListItem›

 ‹asp:ListItem›Элемент 2‹/asp:ListItem›

 ‹asp:ListItem›Элемент 3‹/asp:ListItem›

 ‹asp:ListItem›Элемент 4‹/asp:ListItem›

‹/asp:ListBox›

Заметьте, что здесь элементы ListBox в файле *.aspx указаны явно. Вы уже знаете, что все элементы ‹asp:›, обнаруженные в пределах HTML-формы, автоматически обновляют свое HTML-представление перед отправкой HTTP-ответа (конечно, если они при этом имеют атрибут runat="server").

Директива ‹%@Page%› имеет необязательный атрибут enableViewState, который по умолчанию установлен равным true. Чтобы отменять такое поведение, просто измените содержимое директивы ‹*@Page%› так, как предлагается ниже.

‹%@Page EnableViewState ="false" Language="C#" AutoEventWireup="true" CodeFilе="Dеfault.aspx.cs" Inherits="_Default" %›

Но что же в действительности означает отключение учета состояния представлений? Ответ на этот вопрос зависит от многих факторов. В соответствии с предложенным выше определением данного термина вы могли бы предположить, что при отключении учета состояния представлений для файла *.aspx значения ListBox не будут сохраняться при вторичных запросах к Web-серверу. Однако, выполнив приложение в том виде, в каком это приложение находится сейчас, вы можете с удивлением обнаружить, что информация в ListBox сохраняется независимо от того. сколько раз вы повторно обращаетесь к странице. Фактически, если рассмотреть исходный HTML-код, возвращаемый браузеру, вы увидите, что скрытое поле __VIEWSTATE там все равно присутствует.

‹input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value= "/wEPDwUKMTYlMjcхNTсxNmRkОXbNzW5+R2VDhNWtEtHMM+yhxvU=" /›

Причиной, по которой строка состояния представлений не исчезает, является то, что файл *.aspx явно определяет элементы ListBox в контексте HTML-дескриптора ‹form›. Поэтому элементы ListBox будут автоматически генерироваться при каждом ответе Web-сервера клиенту.

Но предположим, что значения вашего типа ListBox динамически указываются в файле внешнего кода поддержки, а не в рамках HTML-определения ‹form›. Сначала удалите декларации ‹asp:ListItem› из имеющегося файла *.aspx.

‹asp:ListBox ID="myListBox" runat="server"›

‹/asp:ListBox›

Затем задайте элементы списка в обработчике события Load в рамках файла с внешним кодом поддержки.

protected void Page_Load(object sender, EventArgs e) {

 if (!IsPostBack) {

  // Динамическое заполнение ListBox.

  myListBox.Items.Add("Элемент 1");

  myListBox.Items.Add("Элемент 2");

  myListBox.Items.Add("Элемент 3");

  myListBox.Items.Add("Элемент 4");

 }

}

Для обновленной страницы вы обнаружите, что при первом запросе страницы браузером значения в ListBox присутствуют и учитываются. Однако после вторичного запроса ListBox становится пустым. Первым правилом состояния представлений ASP.NET является то, что они учитывается только при наличии элементов, чьи значения динамически генерируются программным кодом. Если вы явно укажете значения в рамках дескриптора ‹form› в файле *.aspx, состояние этих элементов всегда будет восстанавливаться при вторичных запросах (даже если вы установите для enableViewState значение false для данной страницы).

Данные состояния представлений оказываются наиболее полезными при работе с динамическими Web-элементами управления, которые должны обновляться при каждом вторичном обращении к серверу (примером такого Web-элемента является элемент управления GridView ASP.NET, заполняемый при обращении к базе данных). Если вы не отключите учет состояния представлений для страниц, содержащих такие элементы, состояние таблиц будет представлено в скрытом поле__ VIEWSTATE. Сложные страницы могут содержать очень много Web-элементов управления ASP.NET, поэтому вы можете себе представить, насколько большой может быть соответствующая строка. При этом содержимое HTTP-цикла "запрос-ответ" может оказаться достаточно объемным, что может стать определенной проблемой для коммутируемых Web-соединений. В таких случаях может быть оправданным отключение учета состояния представлений для всей страницы.

Если идея отключения учета представлений для всего файла *.aspx кажется вам слишком радикальной, вспомните о том, что каждый потомок базового класса System.Web.UI.Control наследует свойство EnableViewState, с помощью которого очень просто отключить учет состояния представлений для каждого конкретного элемента управления в отдельности.

‹asp:GridView id="myHugeDynamicallyFilledDataGrid" runat="server" EnableViewState="false"›

‹/asp:GridView›

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

В дополнение к свойству EinableViewState базовый класс System.Web. UI.Control предлагает наследуемое свойство ViewState. Это свойство в фоновом режиме обеспечивает доступ к типу System.Web.UI.StateBag, представляющему все данные поля __VIEWSTATE. С помощью индексатора типа StateBag вы можете встроить пользовательскую информацию в скрытое поле __VIEWSTATE формы, используя для этого подходящий набор пар имён и значений. Вот простой пример.

protected void btnAddToVS_Click(object sender, EventArgs е) {

 ViewState["CustomViewStateItem"] = "Пользовательские данные";

 lblVSValue.Text = (string)ViewState["CustomViewStateItem"];

}

Тип System.Web.UI.StateBag может работать с любым типом, производным от System.Object. Поэтому, чтобы получить доступ к значению данного ключа, вам нужно явно преобразовать его в правильный тип данных (в данном случае это тип System.String). При этом следует учесть, что размещаемое в поле __VIEWSTATE значение не может быть абсолютно любым объектом. Единственными действительными типами в данном случае являются строки, цельте числа, булевы значения, типы ArrayList, и Hashtable, а также массивы этих типов.

Но если страницы *.aspx могут вставлять пользовательские фрагменты информации в строку __VIEWSTATE, было бы неплохо выяснить, как это сделать. Как правило, пользовательские данные состояния представлений используются для установки настроек пользователя. Например, вы можете создать элемент данных представления, указывающий то, каким пользователь желает видеть GridView (например, с точки зрения порядка сортировки). Но данные состояния представлений не очень хорошо подходят для "развёрнутых" пользовательских данных, таких как объекты в корзине покупателя, помещенные в кэш типы DataSet или какие-то другие специальные типы. Когда требуется запомнить сложную информацию, лучше работать с сеансовыми данными. Но перед тем как перейти к соответствующему разделу нашего обсуждения, мы должны выяснить роль файла Global.asax.

Исходный код. Файлы примера ViewStateApp размещены в подкаталоге, соответствующем главе 24.

В ASP.NET 2.0 предлагается поддержка состояний элементов управления, а не только состояния представлений. Эта технология оказывается очень удобной при работе с созданными вами Web-элементами управления ASP.NET, которые должны сохранять свои данные между последовательными циклами запросов. Для этого, конечно, можно использовать и свойство ViewState, но если учет состояния представлений будет отключен на уровне страницы, пользовательский элемент управления работать не будет. Именно по этой причине Web-элементы управления теперь поддерживают свойства ControlState.

Состояния элементов управления используются аналогично состояниям представлений, но учет состояния элементов управления не отключается при отключении учета состояния представлений на уровне страницы. Как уже говорилось, эта возможность оказывается наиболее полезной для разработчиков пользовательских Web-элементов управления (обсуждение данной темы в нашей книге не предполагается). За подробностями обратитесь к документации .NET Framework 2.0 SDK.

К этому моменту у вас может сложиться впечатление, что приложение ASP.NET представляет собой простой набор файлов *.аsрх и соответствующих Web-элементов управления. И хотя вы можете построить Web-приложение с помощью простого связывания нескольких Web-страниц, вам, скорее всего, хотелось бы иметь возможность взаимодействия с Web-приложением, как с чем-то цельным. Для этого в Web-приложение ASP.NET можно включить необязательный файл Global.asax, выбрав WebSite>Add New Item из меню (рис. 24.2).

Рис. 24.2. Добавление файла Global.asax

В некотором смысле файл Global.asax в ASP.NET аналогичен традиционному файлу *.exe, поскольку представляет поведение Web-узла в среде выполнения. После добавления файла Global.asax в Web-проект вы обнаружите, что этот файл на самом деле представляет собой блок ‹script›, содержащий набор обработчиков событий.

‹%@ Application Language="C#" %›

‹script runat="server"›

void Application_Start(Object sender, EventArgs e) {

 // Код, выполняемый при запуске приложения.

}

void Application_End(Object sender, EventArgs e) {

 // Код, выполняемый при завершении приложения.

}

void Applicatioт_Error(Object sender, EventArgs e) {

 // Код, выполняемый при появлении необработанной ошибки.

}

void Session_Start(Object sender, EventArgs e) {

 // Код, выполняемый при открытии нового сеанса.

}

void Session_End(Object sender, EventArgs e) {

 // Код, выполняемый при завершении сеанса.

}

‹/script›

Однако первое впечатление может оказаться обманчивым. В среде выполнении программный код этого блока ‹script› преобразуется в тип класса, получающийся из System.Web.HttpApplication. Если вы имеете опыт работы с ASP.NET 1.х, то вы, наверное, вспомните, что там файл с внешним кодом поддержки для Global.asax буквально определял класс, получающийся из HttpApplication.

Как уже было сказано, члены, определённые в Global.asax, содержатся в обработчиках событий, позволяющих взаимодействовать с событиями на уровне приложения (а также сеанса). Описания этих членов предлагаются в табл. 24.1.

Таблица 24.1. Обработчики событий Global.asax

Позвольте указать на роль обработчика событий Application_Error(). Напомним, что страница может использовать обработчик события Error для обработки любого исключения, сгенерированного в контексте страницы и оставшегося без обработки. Обработчик Application_Error() оказывается последним пунктом возможной обработки исключений, которые не были обработаны на уровне страницы. Как и в случае события Error на уровне страницы, вы можете получить доступ к конкретному объекту System.Exception, используя наследуемое свойство Server.

void Application_Error(Object sender, EventArgs e) {

 Exception ex = Server.GetLastError();

 Response.Write(ex.Message);

 Server.ClearError();

}

Обработчик Application Error() является "последним шансом" обработки события для вашего Web-приложения, где вы, вместо предъявления сообщения об ошибке пользователю, можете записать соответствующую информацию в журнал регистрации событий Web-сервера, например:

‹%@ Import Namespace = "System.Diagnostics"%›

…

void Application_Error(Object sender, EventArgs e) {

 // Запись последнего события в журнал событий.

 Exception ex = Server.GetLastError();

 EventLog ev = new EventLog("Application");

 ev.WriteEntry(ex.Message, EventLogEntryType.Error);

 Server.ClearError();

 Response.Write("Это приложение "зависло". Извините!");

}

Как уже говорилось, сценарий Global.asax динамически преобразуется в класс, который получается из базового класса System.Web.HttpApplication и обеспечивает те же функциональные возможности, что и тип System.Web.UI.Page. Описания соответствующих членов предлагаются в табл. 24.2.

Таблица 24.2. Ключевые члены типа System.Web.HttpApplication

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

С другой стороны, данные состояния сеанса используются для сохранения информации, касающейся конкретного пользователя (например, товаров в корзине покупателя). Практически состояние сеанса пользователя представляется типом класса HttpSessionState. При регистрации нового пользователя в Web-прило-жении ASP.NET среда выполнения автоматически назначит этому пользователю новый идентификатор (ID) сеанса, время использования которого по умолчанию истекает после 20 минут неактивности пользователя. Если на вашем узле зарегистрируются 20000 пользователей, вы будете иметь 20000 отдельных объектов HttpSessionState, каждому из которых будет назначен свой уникальный идентификатор сеанса. Схема взаимосвязей между Web-приложением и Web-сеансами показана на рис. 24.3.

Рис. 24.3. Взаимосвязи приложения и его сеансов

Вы, возможно, знаете, что в рамках классической технологии ASP данные состояния приложения и состояния сеанса представляются разными COM-объектами (например, Application и Session). В ASP.NET типы, производные от Page. как и тип HttpApplication, используют свойства с такими же именами (т.е. Application и Session), которые предоставляют доступ к соответствующим типам HttpApplicationState и HttpSessionState.

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

Таблица 24.3. Члены типа HttpApplicationState

Для создания членов-данных, которые должны быть доступны всем активным сеансам, нужно создать множество пар имен и значений. В большинстве случаев наиболее подходящим для этого местом является обработчик события Application_Start() типа, производного от HttpApplication, например:

void Application_Start(Object sender, EventArgs e) {

 // Установка некоторых переменных приложения.

 Application["SalesPersonOfTheMonth"] = "Chucky";

 Application["CurrentCarOnSale"] = "Colt";

 Application["MostPopularColorOnLot"] = "черный";

}

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

protected void btnShowCarDiscunt_Click(object Sender, EventArgs e) {

 // Возвращаемый System.Object следует преобразовать

 // в System.String!

 lblCurrCarOnSale.Text = (string)Application["CurrentCarOnSale"];

}

Как и в случае свойства ViewState, обратите внимание на то, что вы должны преобразовать значение, возвращаемое типом HttpApplicationState, в подходящий тип. Поскольку тип HttpApplicationState может содержать любой тип, должно быть очевидно, что в рамках данных состояния приложения узла вы можете размещать пользовательские типы (и вообще любые типы .NET).

Для примера использования этой возможности создайте новое Web-приложение ASP.NET с названием AppState. Предположим, что требуется поддерживать три текущие переменные приложения в рамках строго типизованного объекта с именем CarLotlInfo.

public class CarLotInfo {

 public CarLotInfo(string s, string c, string m) {

  salesPersonOfTheMonth = s;

  currentCarOnSale = c;

  mostPopularColorOnLot = m;

 }

 // Открыты для простоты доступа.

 public string salesPersonOfTheMonth;

 public string currentCarOnSale;

 public string mostPopularColorOnLot;

}

С этим вспомогательным классом вы можете сначала изменить обработчик события Application_Start() так, как предлагается ниже:

protected void Application_Start(Object sender, EventArgs e)

 // Размещение пользовательского объекта

 // в секторе данных приложения.

 Application["CarSiteInfo"] = new CarLotInfo("Chucky", "Colt" "черный");

}

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

protected void btnShowAppVariables_Click(object sender, EventArgs e) {

 CarLotInfo appVars = ((CarLotInfo)Application["CarSiteInfo"]);

 string appState = string.Format("‹li›Предлагаемая машина: [0]‹/li›", appVars.currentCarOnSale);

 appState += string.Format("‹li›Наиболее популярный цвет: {0}‹/li›", appVars.mostPopularColorOnLot);

 appState += string.Format ("‹li›Наиболее успешный продавец: {0}‹/li›", appVars.salesPersonOfTheMonth);

 lblAppVariables.Text = appState;

}

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

В ходе выполнения Web-приложения с помощью членов типа HttpApplicationState вы можете программно модифицировать или удалить любые или даже все члены уровня приложения. Например, чтобы удалить конкретный элемент, нужно просто вызвать метод Remove(). Чтобы уничтожить все данные уровня приложения, вызовите RemoveAll().

private void CleanAppData() {

 // Удаление отдельного элемента по строковому имени.

 Application.Remove("SomeItemIDontNeed");

 // Удаление всех данных приложения.

 Application.RemoveAll();

}

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

protected void btnSetNewSP_Click(object sender, EventArgs e) {

 // Установка нового имени продавца.

 ((CarLotInfo)Application["CarSiteInfo"]).salesPersonOfTheMonth = txtNewSP.Text;

}

Запустив это Web-приложение, вы увидите, что переменная уровня приложения обновлена. К тому же, поскольку переменные приложения доступны для всех сеансов пользователей, если запустить три или четыре экземпляра Web-браузера, вы увидите, что при изменении имени лучшего продавца одним экземпляром все остальные экземпляры браузера после вторичного обращения к серверу тоже отобразят новое значение.

Следует понимать, что в той ситуации, когда множество переменных уровня приложения должно обновляться как единое целое, есть риск нарушения целостности данных (поскольку теоретически возможно, что данные уровня приложения могут измениться в момент получения к ним доступа со стороны другого пользователя). Можно, конечно, пойти длинным путем и вручную блокировать доступ, используя примитивы потоков из пространства имен System.Threading, но тип HttpApplicationState предлагает два метода, Lock() и Unlock(), которые автоматически гарантируют потоковую безопасность.

// Безопасный доступ к соответствующим данным приложения.

Application.Lock();

Application["SalesPersonOfTheMonth"] = "Maxine";

Application["CurrentBonusedEmployee"] = Application["SalesPersonOfTheMonth"];

Application.Unlock();

Замечание. Во многом аналогично оператору lock в C#, если после вызова Lock(), но перед вызовом Unlock() возникнет исключение, блокировка будет автоматически удалена.

Тип HttpApplicationState предназначен для поддержки значений содержащихся в нем элементов до наступления одного из следующих событий: завершения сеанса доступа последнего пользователя узла (вследствие превышения времени ожидания или закрытия сеанса самим пользователем) или прекращения работы Web-узла вручную с помощью IIS. В любом случае будет автоматически вызван метод Application_Exit() объекта HttpApplication. В этом обработчике события вы можете выполнять любой необходимый вам программный код "уборки".

protected void Application_End(Object sender, EventArgs e) {

 // Запись текущих значений переменных приложения

 // в базу данных или куда-то еще…

}

Исходный Код. Файлы примера AppState размещены в подкаталоге, соответствующем главе 24

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

Как следует из самого названия, объект ASP.NET System.Web.Caching.Cache (доступный с помощью свойства Context.Cache) позволяет определить объект, который будет доступен всем пользователям (всех страниц) в течение определенного периода времени. В простейшей своей форме взаимодействие с объектами кэша аналогично взаимодействию с типом HttpApplicationState.

// Добавление элемента а кэш.

// Этот элемент *не* устареет.

Context.Cache["SomeStringItem"] = "Это строковый элемент";

string s = (string)Context.Cache["SomeStringItem"];

Замечание. Чтобы получить доступ к Cache из Global.asax, необходимо использовать свойство Context. Но в контексте типа, производного от System.Web.UI.Page, вы можете использовать объект Cache непосредственно.

Следует понимать, что в отсутствие необходимости автоматически обновлять (или удалять) данные уровня приложения (как в нашем случае), объект Cache не дает особых преимуществ, поскольку тогда можно непосредственно использовать тип HttpApplicationState. Но когда вы хотите, чтобы некоторые данные по прошествии определенного времени уничтожались (и, возможно, об этом сообщалось), тогда тип Cache оказывается чрезвычайно полезным.

Класс System.Web.Caching.Cache вне рамок индексатора типа определяет весьма ограниченный набор членов. Например, метод Add() можно использовать для добавления в кэш нового элемента, не определенного в данный момент (если указанный элемент уже имеется, Add() ничего не делает). Метод Insert() также помещает член в кэш. Однако если такой элемент уже определен, Insert() заменит текущий элемент новым типом. Поскольку именно это и требуется чаще всего, мы рассмотрим подробно только метод Insert().

Рассмотрим простой пример. Создайте новое Web-приложение ASP.NET с названием CacheState и добавьте в это приложение файл Global.asax. Подобно переменным уровня приложения, определяемым с помощью типа HttpApplicationState. тип Cache может содержать любой тип System.Object, а его значения часто задаются в обработчике событий ApplicationStart(). Для нашего примера целью является автоматическое обновление содержимого DataSet каждые 15 секунд. Этот тип DataSet будет содержать текущий набор записей из таблицы Inventory базы данных Cars, созданной нами при обсуждении ADO.NET. С учетом этого обновите свой тип класса Global так, как показано ниже (сразу же после листинга предлагается анализ этого программного кода).

‹%@ Application Language="C#" %›

‹%@ Import Namespace = "System.Data.SqlClient" %›

‹%@ Import Namespace = "System.Data" %›

‹script runat="server"›

// Определение статического члена-переменной типа Cache.

static Cache theCache;

void Application_Start(Object sender, EventArgs e) {

 // Присваивание значения статической переменной 'theCache' .

 theCache = Context.Cache;

 // При запуске приложения читается текущая запись

 // таблицы Inventory базы данных Cars.

 SqlConnection cn = new SqlConnection("data source=localhost;initial catalog=Cars; user id='sa';pwd=''");

 SqlDataAdapter dAdapt = new SqlDataAdapter("Select * From Inventory", cn);

 DataSet theCars = new dataSet(); dAdapt.Fill(theCars, "Inventory");

 // Сохранение DataSet в кэше.

 theCache.Insert("AppDataSet", theCars, null,

  DateTime.Now.AddSeconds(15), Cache.NoSlidingExpiration, CacheItemPrioritу.Default,

  new CacheItemRemovedCallback(UpdateCarInventory));

}

// Цель делегата CacheItemRemovedCallback.

static void UpdateCarInventorу(string key, object item, CacheItemRemovedReason reason) {

 // Заполнение DataSet.

 SqlConnection cn = new SqlConnection("data source=localhost;initial catalog=Cars; user id = 'sa';pwd=''");

 SqlDataAdapter dAdapt = new SqlDataAdapter("Select * From Inventory", cn);

 DataSet theCars = new DataSet();

 dAdapt.Fill(theCars, "Inventory");

 // Сохранение в кэше.

 theCache.Insert("AppDataSet", theCars, null,

  DateTime.Now.AddSeconds(15), Cache.NoSlidingExpiration, CacheItemPriority.Default,

  new CasheItemRemovedCallback(UpdateCarInventory));

}

…

‹/script›

Сначала обратите внимание на то, что тип Global определяет статическую переменную типа Cache. Причина в том, что определяется также статическая функция (UpdateCarInventory()), которой требуется доступ к Cache (напомним, что статические члены не имеют доступа к наследуемым членам, поэтому в данном случае вы не сможете использовать свойство Context).

Внутри обработчика событий Application_Start() заполняется тип DataSet, который затем помещается в кэш приложения. Должно быть ясно, что метод Context.Cache.Insert() перегружен. Ниже объясняются значения каждого из параметров этого метода.

// Сохранение в кэше.

theCache.Insert("AppDataSet", // Имя для идентификации элемента.

 theCars, // Объект для отправки в кэш.

 null, // Зависимости для объекта.

 DateTime.Now.AddSeconds(15), // Длительность пребывания в кэше.

 Cache.NoSlidingExpiration, // Фиксированное или скользящее время.

 CacheItemPriority.Default, // Приоритет элемента.

 // Делегат для события CacheItemRemove.

 new CacheItemRemovedCallback(UpdateCarInventory));

Первые два параметра просто формируют пару "имя-значение" элемента. Третий параметр позволяет определить тип Cache Dependency (который в данном случае будет равен null, поскольку у вас в кэше нет элементов, зависящих от DataSet).

Замечание. Возможность определить тип CacheDependency довольно привлекательна. Например, можно указать зависимость между некоторым членом и внешним файлом, и если содержимое файла изменится, соответствующий тип автоматически обновится. Все подробности можно найти в документации .NET Framework 2.0.

Следующие три параметра используются для определения приоритета элемента и времени, в течение которого элементу позволяется оставаться в кэше приложения. Здесь указывается доступное только для чтения поле Cache.NoSlidingExpiration, которое указывает, что указанный промежуток времени (15 секунд) является абсолютным. Наконец, и это самое важное для данного примера, создается тип делегата CacheItemRemovedCallback, которому передается имя метода, вызываемого при очистке DataSet. Как следует из структуры метода UpdateCarInventory(), делегат CacheItemRemovedCallback может вызвать только методы со следующей сигнатурой.

static void UpdateCarInventory(string key, object item, CacheItemRemovedReason reason) {…}

Теперь при запуске приложения тип DataSet будет заполнен и помещен в кэш. Каждые 15 секунд DataSet будет очищаться, обновляться и снова помещаться в кэш. Чтобы увидеть результат этих действий, мы должны создать тип Page, который будет позволять некоторую степень взаимодействия с пользователем.

Обновите пользовательский интерфейс исходного файла *.aspx так, как показано на рис. 24.4.

В обработчике события Load страницы настройте GridView на отображение содержимого помещенного в кэш типа DataSet при первом обращении пользователя к странице.

protected void Page_Load(object sender, EventArgs e) {

 if (!IsPostBack) {

  carsGridView.DataSource = (DataSet)Cache["AppDataSet"];

  carsGridView.DataBind();

 }

}

Рис. 24.4. Графический интерфейс пользователя для приложения с кэшированием

В обработчике события Click кнопки Добавить эту машину вставьте новую запись в базу данных Cars, используя для этого объект ADO.NET SqlCommand. После добавления записи вызовите вспомогательную функцию RefreshGrid(), которая обновит интерфейс с помощью типа SqlDataReader (поэтому не забудьте указать using для пространства имен System.Data.SqlClient). Вот как должны выглядеть соответствующие методы,

protected void btnAddCar_Click(object sender, EventArgs e) {

 // Обновление таблицы Inventory

 // и вызов RefreshGrid().

 SqlConnection cn = new SqlConnection();

 cn.ConnectionString = "User ID=sa;Pwd=;Initial Catalog=Cars;Data Source=(local)";

 cn.Open();

 string sql;

 SqlCommand cmd;

 // Вставка нового Car.

 sql = string.Format(

  "INSERT INTO Inventory(CarID, Make, Color, PetName) VALUES" +

  "('{0}', '{1}', '{2} ', '{3}')",

  txtCarID.Text, txtCarMake.Text,

  txtCarColor.Text, txtCarPetName.Text);

 cmd = new SqlCommand(sql, cn);

 cmd.ExecuteNonQuery();

 cn.Close();

 RefreshGrid();

}

private void RefreshGrid() {

 // Заполнение таблицы.

 SqlConnection cn = new SqlConnection();

 cn.ConnectionString = "User ID=sa;Pwd=;Initial Catalog=Cars;Data Source=(local)";

 cn.Open();

 SqlCommand cmd = new SqlCommand("Select * from Inventory", cn);

 carsGridView.DataSource = cmd.ExecuteReader();

 carsGridView.DataBind();

 cn.Close();

}

Теперь, чтобы проверить использование кэша, запустите два экземпляра вашего Web-браузера и перейдите к этой странице *.aspx. Вы должны увидеть, что оба типа DataGrid отображают одинаковую информацию. В окне одного из экземпляров браузера добавьте новую машину. Очевидно, что в результате вы увидите обновленные данные GridView в окне браузера, который инициировал обращение к источнику данных.

Во втором экземпляре браузера щелкните на кнопке Обновить. Вы не увидите новый элемент, поскольку обработчик события Page_Load читает данные непосредственно из кэша. (Если же вы увидели новые данные, это значит, что уже истекли 15 секунд. Либо печатайте быстрее, либо увеличьте время, в течение которого тип DataSet должен оставаться в кэше.) Подождите несколько секунд и снова щелкните на кнопке Обновить второго экземпляра браузера. Теперь вы должны увидеть новые данные, поскольку время пребывания DataSet в кэше истекло, и целевой метод делегата CacheItemRemovedCallback автоматически обновил тип DataSet, помещенный в кэш.

Как видите, главное преимущество типа Cache заключается в том, что вы получаете возможность ответить на удаление члена. В этом примере вы, конечно, можете избежать использования типа Cache путем чтения данных в обработчике Page_Load() непосредственно из базы данных Cars. Однако теперь вам должно быть ясно, что кэш позволяет автоматически обновлять данные с помощью делегатов .NET.

Замечание. В отличие от типа HttpApplicationState, класс Cache не поддерживает методы Lock() и Unlock(). Так что при необходимости обновить связанные элементы вам придется использовать типы из пространства имен System.Threading или ключевое слово lock C#.

Исходный код. Файлы примера CacheState размещены в подкаталоге, соответствующем главе 24.

Поговорив о данных уровня приложения, давайте перейдем к обсуждению данных, создаваемых на уровне пользователя. Как уже упоминалось, сеанс на самом деде представляет собой процесс взаимодействие пользователя с Web-приложением, представленный типом HttpSessionState. Для поддержки информации сеанса конкретного пользователя объект HttpApplication и любые другие типы System.Web.UI.Page могут использовать доступ к свойству Session. Классическим примером необходимости поддержки пользовательских данных является корзина покупателя: при подключении десятков посетителей к странице Интернет-магазина для каждого посетителя должен поддерживаться уникальный список товаров, которые этот посетитель собрался купить.

При регистрации нового пользователя в Web-приложении среда выполнения .NET автоматически назначит пользователю уникальный идентификатор сеанса, используемый для идентификации данного пользователя. С каждым идентификатором сеанса ассоциируется пользовательский экземпляр типа HttpSessionState, который будет содержать данные соответствующего пользователя. Технология добавления и чтения сеансовых данных синтаксически идентична работе c данными приложения, например:

// Добавление/чтение сеансовой переменной для данного пользователя.

Session["DesiredCarColor"] = "зеленый";

String color = (string)Session["DesiredCarColor"];

Производный от HttpApplication тип позволяет выполнить перехват событий начала и завершения сеанса с помощью обработчиков событий Session_Start() и Session_End(). В пределах Session_Start() вы можете создать любые элементы данных пользователя, а в Session_End() можно выполнить любые действия, необходимые при завершения сеанса пользователя.

‹%@ Application Language="C#" %›

‹script runat="server"›

…

void Session_Start(objecl sender, EventArgs e) {}

void Session_End(object sender, EventArgs e) {}

‹/script›

Подобно типу HttpApplicationState, тип HttpSessionState может содержать любой тип, производный от System.Object, включая пользовательские классы. Предположим, например, что у нас есть новое Web-приложение (SessionState), которое определяет вспомогательный класс с именем UserShoppingCart.

public class UserShoppingCart {

 public string desiredCar;

 public string desiredCarColor;

 public float downPayment;

 public bool isLessing;

 public DateTime dateOfPickUp;

 public override string ToString() {

  return string.Format("Машина: {0}‹br›Цвет: {1}‹br›$ кредит: {2}‹br›" +

   "Аренда: {3}‹br›Доставка: {4}",

   desiredCar, desiredCarColor, downPayment, isLeasing,

   dateOfPickUp.ToShortDateString());

 }

}

В обработчике событий Session_Start() можно назначить каждому пользователю свой экземпляр класса UserShoppingCart.

void Session_Start(Object sender, EventArgs e) {

 Session["UserShoppingCartInfo"] = new UserShoppingCart();

}

При просмотре ваших Web-страниц пользователем вы можете взять экземпляр UserShoppingCart и заполнить его поля данными соответствующего пользователя. Предположим, что у вас есть простая страница *.aspx с набором элементов ввода, соответствующих каждому полю типа UserShoppingCart, и кнопкой (Button), используемой для установки введенных значений (рис. 24.5).

Рис. 24.5. Графический интерфейс пользователя для приложения с сеансовыми данными

Серверный обработчик события Click действует весьма прямолинейно (считывает значения элементов TextBox и отображает поступающие значения в поле типа Label).

protected void btnSubmit_Click(object sender, EventArgs e) {

 // Установка преференций текущего пользователя.

 UserShoppingCart u = (UserShoppingCart)Session["UserShoppingCartInfo"];

 u.DateOfPickUp = myCalendar.SelectedDate;

 u.desiredCar = txtCarMake.Text;

 u.desiredCarColor = txtCarColor.Text;

 u.downPayment = float.Parse(txtDownPayment.Text);

 u.isLeasing = chkisLeasing.Checked;

 lblUserInfo.Text = u.ToString();

 Session["UserShoppingCartInfo"] = u;

}

В Session_End() вы можете, например, сохранить значения полей UserShoppingCart в базе данных или выполнить какие-то иные действия. Так или иначе, если Вы запустите два или три экземпляра своего браузера, вы должны увидеть, что каждый пользователь может создать свою корзину покупателя, связанную с его уникальным экземпляром HttpSessionState.

Кроме индексатора типа, класс HttpSessionState определяет ряд других интересных членов. Во-первых, свойство SessionID возвращает уникальный идентификатор текущего пользователя.

lblUserID.Text = string.Format("Значение вашего ID: {0}", Session.SessionID);

Методы Remove() и RemoveAll() можно использовать для удаления элементов из экземпляра HttpSessionState пользователя.

Session.Remove["НекоторыеУжеНенужныеЭлементы"];

Тип HttpSessionState определяет также набор членов, управляющих значениями времени ожидания для текущего сеанса. Снова подчеркнем, что по умолчанию каждому пользователю позволяется 20 минут бездействия до того, как объект HttpSessinState будет уничтожен. Поэтому если пользователь войдет в ваше Web-приложение (и получит в результате этого свое уникальное значение идентификатора сеанса), но не будет обращаться к узлу в течение 20 минут, среда выполнения "решит", что пользователь больше не интересуется узлом и уничтожает все сеансовые данные этого пользователя. Вы имеете возможность изменить это принятое по умолчанию 20-минутное значение для каждого пользователя в отдельности, используя свойство Timeout. Чаще всего для такого изменения используется контекст метода Global.Session_Start().

protected void Session_Start(Object sender, EventArgs e) {

 // Пользователю разрешается 5 минут бездействия.

 Session.Timeout = 5;

 Session["UserShoppingCartInfo"] = new UserShoppingCart();

}

Замечание. Чтобы не менять значение Timeout каждого пользователя, вы можете изменить принятое по умолчанию 20-минутное значение для всех пользователей сразу с помощью атрибута Timeout элемента ‹sessionState› в файле Web.config (структура и возможности этого файла будут рассмотрены в конце главы).

Преимущество использования свойства Timeout заключается в том, что вы можете назначить свои значения времени ожидания для каждого пользователя в отдельности. Например, представьте себе, что ваше Web-приложение позволяет пользователям заплатить за некоторый уровень членства. Вы можете потребовать, чтобы "золотым" членам устанавливалось время ожидания, равное одному часу, а "деревянным" – только 30 секунд. Такая возможность порождает следующий вопрос: как реализовать запоминание соответствующей информации пользователя (например, текущий уровень его членства) между обращениями к Web-странице? Одной из возможностей является использование типа HttpCookie.

Исходный код, Файлы примера SessionState размещены в подкаталоге, соответствующем главе 24.

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

Получающая запрос Web-страница на сервере может прочитать данные cookie, чтобы использовать их при создании графического интерфейса, учитывающего текущие предпочтения пользователя. Уверен, при посещении своих любимых Web-узлов вы замечали, что узел как будто знает, какого сорта содержимое вы хотите видеть. Например, при регистрации на странице http://www.ministryofsound.com мне автоматически предъявляется содержимое, отвечающее моим музыкальным вкусам. Причиной (отчасти) является то, что на моем компьютере были сохранены данные cookie с информацией о том типе музыки, которую я предпочитаю слушать.

Точное место хранения файлов cookie зависит от используемого вами браузера. При использовании Microsoft Internet Explorer файлы cookie по умолчанию сохраняются в папке C:\Documents and Sеttinngs\‹имяПользователя›\Cookies (рис. 24.6).

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

Рис. 24.6. Данные cookie, сохраненные браузером Microsoft Internet Explorer

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

Замечание. Большинство браузеров поддерживает строки cookie длиной до 4096 байт. Из-за такого ограничения строки cookie лучше всего использовать для запоминания небольших фрагментов данных, например идентификаторов пользователей, с помощью которых затем можно получить дополнительные данные из базы данных.

Тип System.Web.HttpCookie является классом, представляющим серверную часть данных cookie (перманентных или временных). Для создания новых данных cookie используется свойство Response.Cookies. После вставки нового объекта HttpCookie во внутреннюю коллекцию) соответствующие пары имен и значений направляются обратно браузеру в пределах заголовка HTTP.

Для примера использования данных cookie создайте новое Web-приложение ASP.NET (CookieStateApp) с пользовательским интерфейсом, изображенным на рис. 24.7.

В обработчике события Сlick кнопки создайте новый тип HttpCookie и вставьте его в коллекцию Cookie, доступную с помощью свойства HttpRequest.Cookies.

Рис. 24.7. Пользовательский интерфейс приложения CookieStateApp

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

protected void btnInsertCookie_Click (object sender, EventArgs e) {

 // Создание новых (временных) данных cookie.

 HttpCookie theCookie = new HttpCookie(txtCookieName.Text, txtCookieValue.Text);

 Response.Cookies.Add(theCookie);

}

Однако следующий фрагмент программного кода генерирует перманентные данные cookie, срок действия которых истечет 24 марта 2009 года.

private void btnInsertCookie_Click(object sender, EventArgs e) {

 // Создание новых (перманентных) данных cookie.

 HttpCookie theCookie = new HttpCookie(txtCookieName.Text, txtCookieValue.Text);

 theCookie.Expires = DateTime.Parse("03/24/2009");

 Response.Cookies.Add(theCookie);

}

Запустив это приложение и добавив некоторые данные cookie, вы сможете проверить, что браузер автоматически сохранит эти данные на диске. Открыв соответствующий текстовый файл, вы увидите нечто, подобное показанному на рис. 24.8.

Рис. 24.8. Перманентные данные cookie

Напомним, что именно браузер отвечает за возможность доступа к перманентным данным cookie во время обращения к ранее посещавшейся странице. Для взаимодействия с поступающими данными cookie в ASP.NET предусмотрено свойство HttpRequest.Cookies. Например, если вы хотите обновить пользовательский интерфейс вашего приложения с тем, чтобы можно было отобразить текущие данные cookie с помощью элемента управления Button, вы можете реализовать цикл по всем парам имея и значений, представляя соответствующую информацию в поле элемента Label.

protected void btnShowCookies_Click(object sender, EventArgs e) {

 string cookieData = "";

 foreach(string s in Request.Cookies) {

  cookieData += string.format("‹li›‹b›Имя‹/b›: {0}, ‹b›Значение‹/b›: {1}‹/li›", s, Request.Cookies[s].Value);

 }

 lblCookieData.Text = cookieData;

}

Если теперь запустить приложение и щелкнуть на новой кнопке, вы увидите, что данные cookie вашим браузером действительно посылаются (рис. 24.9).

Рис. 24.9. Просмотр данных cookie

К этому моменту мы с вами рассмотрели множество способов запоминания информации о пользователях. Вы видели, что данные состояния представлений и данные приложения, кэша, сеанса и cookie обрабатываются примерно одинаково (с помощью индексатора класса). Вы также видели, что тип HttpApplication часто используется для перехвата и обработки событий, происходящих в течение всего времени существования Web-приложения. Следующей нашей задачей является выяснение роли файла Web.config.

Исходный код. Файлы примера CookieStateApp размещены в подкаталоге, соответствующем главе 24.

При изучении компоновочных блоков .NET мы с вами выяснили, что приложения клиента могут использовать XML-файл конфигурации, содержащий инструкции CLR о том, как обрабатывать связанные запросы, где искать необходимые компоновочные блоки и что еще нужно учесть в среде выполнения. То же можно сказать и в случае Web-приложений ASP.NET, но в данном случае файлы конфигурации (впервые упомянутые в главе 23) всегда называются Web.config (в отличие от файлов конфигурации *.exe, имена которых зависят от имен соответствующих выполняемых файлов клиента).

При добавлении файла Web.config к файлам узла с помощью выбора WebSite>Add New Item из меню создаваемая по умолчанию структура выглядит примерно так, как показано ниже (чтобы не загромождать структуру, комментарии здесь были исключены).

‹?xml version="1.0"?›

 ‹configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"›

  ‹appSettings/›

  ‹connectionStrings/›

  ‹system.web›

   ‹compilation debug="false"/›

   ‹authentication mode="Windows"/›

  ‹/system.web›

‹/configuration›

Подобно любому файлу *.config, в файле Web.config определяется корневой элемент ‹configuration›. В его контекст вкладывается элемент ‹system.web›, который может содержать множество дочерних элементов, с помощью которых осуществляется управление поведением Web-приложения в среде выполнения. В ASP.NET файл Web.config можно модифицировать с помощью любого текстового редактора. Некоторые элементы, которым позволено присутствовать в файле Web.config, описаны в табл. 24.4.

Замечание. Чтобы выяснить подробности формата файла Web.config, выполните поиск разделов документации .NET Framework 2.0 SDK, соответствующих ключу поиска "ASP.NET Settings Schema".

Таблица 24.4. Подборка элементов файла

Файл Web.config может содержать дополнительные элементы, размещенные как до, так и после элементов, представленных в табл. 24.4. Большинство этих эле-ментов связано с безопасностью, а остальные оказываются полезными только для построении достаточно сложных сценариев ASP.NET, предполагающих, например, создание пользовательских HTTP-заголовков или пользовательских HTTP-модулей (эти вопросы здесь обсуждать не планируется). Если вам нужен полный комплект элементов, допустимых для использования в файле Web.config, поищите по ключу "ASP.NET Settings Schema" в системе оперативной справки.

Первым элементом файла Web.config, который мы собираемся здесь рассмотреть, будет элемент ‹trace›. Этот XML-дескриптор может иметь любое число атрибутов, задающих особенности его поведения, как показано в следующем примере.

‹trace

 enabled="true|false"

 localOnly= "true|false"

 pageOutput="true|false"

 requestLimit="integer"

 traceMode="SortByTima|SortByCategory"/›

Описания этих атрибутов предлагаются в табл. 24.5.

Таблица 24.5. Атрибуты элемента ‹trace›

Вспомните из предыдущей главы, что с помощью директивы ‹%@Page%› можно разрешить трассировку отдельных страниц. Но если вы хотите разрешить трассировку для всех страниц Web-приложения, измените ‹trace› в файле Web.config, как показано ниже.

‹trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" /›

Элемент ‹customErrors› может использоваться для автоматического перенаправления всех ошибок в пользовательский набор файлов *.htm. Это может оказаться полезным тогда, когда вы хотите построить более понятную для пользователя страницу информирования об ошибках по сравнению с той, которая предлагается средой CLR по умолчанию. В общем виде элемент ‹customErrors› выглядит так.

‹customErrors defaultRedirect="url" mode="On|Off|RemoteOnly"›

 ‹error statusCode="код_состояния" redirect="url"/›

‹/customErrors›

Чтобы предъявить пример применения элемента ‹customErrors›, предположим, что Web-приложение ASP.NET имеет два файла *.htm. Первый файл (genericError.htm) функционирует, как страница перехвата ошибок. Эта страница может содержать логотип вашей компании, ссылку на адрес электронной почты администратора системы и, например, сообщение с извинениями за доставленные пользователю неудобства. Второй файл (Error404.htm) – это пользовательская страница ошибки, которая должна появляться только тогда, когда среда выполнения обнаруживает ошибку с номером 404 (грозная ошибка "необнаруженного ресурса"). Если вы хотите, чтобы все ошибки обрабатывались этими пользовательскими страницами, вы можете изменить файл Web.config так, как предлагается ниже.

‹?xml version="1.0"?›

‹configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"›

 ‹appSettings/›

 ‹connectionStrings /›

 ‹system.web›

  ‹compilation debug= "false" /›

  ‹authentication mode="Windows"/›

  ‹customErrors defaultRedirect="genericError.htm" mode="On"›

   ‹error statusCodes="404" redirect="Error404.htm"/›

  ‹/customErrors›

 ‹/system.web›

‹/configuration›

Обратите внимание на то, что корневой элемент ‹customErrors› используется для указания имени общей страницы для всех необработанных ошибок. Одним из атрибутов, которые могут присутствовать в открывающем дескрипторе, является атрибут mode. Значением, устанавливаемым для этого атрибута по умолчанию, является RemoteOnly, дающее указание среде выполнения не отображать пользовательские страницы ошибок, если HTTP-запрос поступает с той же машины, где находится Web-cервер (это очень удобно для разработчиков, которым требуется видеть все подробности). Если установить для атрибута mode значение "on", это позволит видеть пользовательские ошибки на всех машинах (включая машину разработки). Также заметьте, что элемент ‹customErrors› может поддерживать любое число вложенных элементов ‹error›, с помощью которых можно указать, какая страница должна иcпользоваться для ошибки с тем или иным кодом.

Чтобы проверить работу пользовательского перенаправления ошибок, создайте страницу *.aspx с двумя элементами управления Button и обработайте их события Click так, как предлагается ниже.

private void btnGeneralError_Click(object sender, EventArgs e) {

 // Это генерирует ошибку общего вида.

 throw new Exception("Ошибка общего вида…");

}

private void btn404Error_Click(object sender, EventArgs e) {

 // Это генерирует ошибку 404 (при отсутствии файла MyPage.aspx).

 Response.Redirect("MyPage.aspx");

}

Наиболее мощным элементом файла Web.config является ‹sessionState›. По умолчанию ASP.NET запоминает данные сеансового состояния с помощью *.dll в рамках рабочего процесса ASP.NET (aspnet_wp.exe). Подобно любому файлу *.dll. положительным моментом его использования является то, что доступ к информации оказывается настолько быстрым, насколько это возможно. Однако недостатком оказывается то, что в случае аварийного завершения работы этого домена приложения (по любой причине) будут потеряны все данные пользователя. К тому же, когда вы храните данные в *.dll внутри процесса, вы не можете взаимодействовать с сетевой Web-группой. По умолчанию элемент ‹sessionState› файла Web.config выглядит примерно так.

‹sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /›

Принятый по умолчанию режим хранения оказывается вполне подходящим только в том случае, когда ваше приложение обслуживается в рамках одного Web-сервера. Но в ASP.NET вы можете дать указание среде выполнения обслуживать *.dll сеансового состояния в суррогатном процессе, называемом сервером сеансового состояния ASP.NET (aspnet_state.exe). Тем самым вы можете вывести *.dll из aspnet_wp.exe в отдельный *.exe. Первым шагом при этом должен быть запуск службы aspnet_state.exe Windows. С этой целью введите в командной строке

net start aspnet_state

Запустить aspnet_state.exe можно и по-другому, с помощью оснастки Службы, доступной из папки Администрирование панели управления Windows (рис. 24.10).

Рис. 24.10. Оснастка Services Windows

Преимуществом этого подхода является то, что с помощью окна свойств вы можете настроить aspnet_state.exe на автоматический старт при загрузке машины. В любом случае, запустив сервер состояния сеанса, измените элемент ‹sessionState› в файле Web.config так, как показано ниже.

‹sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/›

Здесь атрибут mode устанавливается равным StateServer. Это именно то, что требуется. Теперь CLR обслуживает данные сеанса в рамках aspnet_state.exe. В этом случае, если домен приложения, содержащий само Web-приложение, завершится аварийно, сеансовые данные сохранятся. Также заметьте, что элемент ‹sessionState› может содержать атрибут stateConnectionString. Принятое по умолчанию значение (127.0.0.1) для адреса TCP/IP указывает на локальную машину. Если вместо этого вы хотите, чтобы среда выполнения .NET использовала сервис aspnet_state.exe на другой машине в сети (снова подумайте о Web-группе), вы имеете возможность изменить это значение.

Наконец, если требуется наивысшая степень изолированности и устойчивости дли Web-приложения, вы можете "заставить" среду выполнения сохранять все данные состояния сеанса в Microsoft SQL Server. Соответствующая модификация файла Web.config снова очень проста.

‹sessionState mode="SQLServer" stateConnectionString="tcpip=l27.0.0.1:42424" sqlConnectionString="data sourse=127.0.0.1;Trusted_Connection=yes'' cookieless="false" timeout="20" /›

Однако перед тем как вы попытаетесь выполнять соответствующее Web-приложение, вы должны обеспечить правильную настройку целевой машины (указанной атрибутом sqlConnectionString). При установке .NET Framework 2.0 SDK (или Visual Studio 2005) создаются два файла, InstallSqlState.sql и UninstallSqlScate.sql, которые по умолчанию помещаются в папку ‹%windir%›\Microsoft.NET\Framework\‹версия›. На целевой машине вы должны выполнить файл InstallSqlState.sql, используя, например, SQL Server Query Analyzer (который входит в поставку Microsoft SQL Server).

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

Замечание. Если для хранения сеансовых данных используется сервер состояния сеанса ASP.NET или SQL Server, то любой пользовательский тип, размещаемый в объекте HttpSessionState, должен быть обозначен атрибутом [Serializable].

В завершение этого раздела главы следует упомянуть тот факт, что ASP.NET 2.0 теперь предлагает Web-утилиту конфигурации для управления множеством установок в файле Web.config узла. Чтобы активизировать эту утилиту (рис. 24.11), выберите Web Site>ASP.NET Configuration из меню Visual Studio 2005.

Рис. 24.11. Утилита администрирования узла ASP.NET 2.0

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

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

Если у вас есть Web-приложение ASP.NET, содержащее необязательные подкаталога в корневом каталоге, вы с удивлением обнаружите, что каждый такой подкаталог может иметь собственный файл Web.config. Это дает возможность каждому подкаталогу переопределить установки родительского каталога. Если подкаталог не имеет своего пользовательского файла Web.config, каталог наследует установки следующего файла Web.config, размещенного выше по структуре каталога. Такой подход как это ни странно звучит, позволяет перенести определенные принципы ООП на структуру каталогов. Соответствующая концепция иллюстрируется схемой, представленной на рис. 24.12.

Рис. 24.12. Наследование конфигурации

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

Замечание. Вспомните из плавы 11, что файл machine.config определяет различные установки на уровне машины, многие из которых связаны с ASP.NET. Этот файл является наивысшим в иерархии наследования конфигурации.

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

Замечание. Если вам требуется более глубоко изучить ASP.NET 2.0, обратитесь к книге Мэтью Мак-Дональда и Марио Шпушта, Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов (ИД "Вильямс", 2006 г.).

В завершение нашего путешествия в последней главе будет рассмотрена тема создания Web-сервисов XML в .NET 2.0.

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

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

Глава 18 информировала вас о слое удаленного взаимодействия .NET. Вы смогли убедиться в том, что эта технология позволяет любой группе компьютеров с поддержкой .NET осуществлять обмен информацией через границы машин. Это, конечно, прекрасно, но одним из ограничений слоя удаленного взаимодействия .NET оказывается то, что для каждой из участвующих в обмене сторон требуется установка .NET Framework, поддержка CTS и использование одинакового формата сетевого обмена (например, TCP).

Web-сервисы XML предлагают более гибкую альтернативу в деле построения распределенных приложений. Говоря простыми словами, Web-cepвuc XML - это единица программного кода, обслуживаемая Web-сервером и доступная в рамках стандартных промышленных технологий, например, таких как HTTP и XML. Вы, наверное, догадываетесь, что благодаря использованию "нейтральных" технологий Web-сервисы XML предлагают такой уровень совместимости и взаимодействия в отношении операционных систем, платформ и языков, который ранее был просто недоступен.

Из этой последней главы книга вы узнаете о том, как создаются Web-сервисы XML в рамках платформы .NET. В процессе обсуждения основной темы мы рассмотрим также ряд связанных вопросов, в частности службы поиска (UDDI и DISCO), язык WSDL и протокол SOAP. Выяснив, как строить Web-сервисы XML, мы рассмотрим различные возможности генерирования агентов клиента, способных вызывать "Web-методы" в синхронном и асинхронном режимах.

С точки зрения самого высокого уровня вы можете определить Web-сервис XML, как единицу программного кода, доступную для вызова с помощью HTTP-запросов. Однако, в отличие от традиционного Web-приложения, Web-сервисы XML можно использовать не только для того, чтобы возвращать браузеру HTML-код с целью визуализации. Скорее наоборот, Web-сервис XML чаще всего предоставляет функциональные возможности, аналогичные возможностям стандартной библиотеки программного кода .NET (например, специальные вычисления, выборку данных из DataSet, чтение цен на акции и т.д.).

На первый взгляд, Web-сервисы XML могут показаться просто очередной новой технологией удаленного взаимодействия. Это, конечно, так и есть, но давайте рассмотрим эту технологию чуть подробнее. Исторически для доступа к удаленным объектам всегда требовались специальные зависящие от платформы (a часто и от языка) протоколы (DCOM, Java RMI и т.д). Проблема такого подхода заключается не в лежащей в его основе технологии, а в том, что каждая из сторон замыкается в своем специфическом сетевом формате. Поэтому при попытке построения распределенной системы, в которой используется множество операционных систем, каждой машине приходится согласовывать формат пакета данных, протокол передачи и т.д. С целью упрощения ситуации Web-сервисы XML позволяют вызывать методы и свойства удаленного объекта с помощью стандартных HTTP-запросов. Из всех протоколов, существующих на сегодняшний день, HTTP является единственным сетевым протоколом, с которым "согласны" все платформы (в конце концов, HTTP – это основа World Wide Web).

Другой фундаментальной проблемой использования частных архитектур удаленного взаимодействия является то, что все они требуют, чтобы отправитель и получатель "понимали" одну и ту же систему базовых типов. Однако, и вы с этим должны согласиться, arrayList Java имеет мало общего с ArrayList .NET, и оба они не имеют ничего общего с массивом C++, Web-сервисы XML обеспечивают возможность гармоничного обмена информацией для несовместимых платформ, операционных систем и языков программирования. Вместо того чтобы вынуждать вызывающую сторону понимать специальную систему типов, информация между системами передается в виде XML-данных (которые на поверку оказываются "правильно" форматированными строками). Основным правилом здесь является следующее: если ваша операционная система позволяет оперативный доступ и анализ символьных данных, она способна взаимодействовать и с Web-сервисом XML.

Замечание. Web-сервис XML Microsoft .NET производственного уровня о6служивается сервером IIS в рамках отдельного виртуального каталога. Однако, как говорилось в главе 23, с помощью WebDev.WebServer.exe в .NET 2.0 теперь можно загружать Web-содержимое и из локального каталога (при разработке и тестировании).

Одной особенностью Web-сервисов XML, которая может сначала казаться непонятной, является то, что "потребителем" Web-сервисов XML являются не только Web-страницы. Консольные клиенты и клиенты Windows Forms тоже могут использовать Web-сервисы. В любом случае потребитель Web-cервиса XML неявно взаимодействует с удаленным Web-сервисом XML, с помощью промежуточного типа агента (proxy).

Агент Web-сервиса XML выглядит и ведет себя в точности так, как настоящий удаленный объект, предлагая при этом тот же набор членов. Однако "за кулисами" программный код агента направляет запросы Web-сервису XML, используя стандартные возможности HTTP. Агент также отображает поступающий поток XML-данных в соответствующие типы данных .NET (или любую другую систему типов, понятных приложению потребителя). На рис. 25.1 показана базовая схема взаимодействия Web-сервисов XML.

Рис. 25.1. Web-сервисы XML в действии

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

• служба поиска (позволяющая клиентам выяснить место нахождения Web-сервиса XML);

• служба описания (позволяющая клиентам узнать, что может предложить Web-сервис XML);

• транспортный протокол (позволяющий обмениваться информацией между клиентом и Web-сервисом XML).

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

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

Для этого вы можете зарегистрировать свой Web-сервис XML на сервере UDDI (Universal Description, Discovery, and Integration – универсальное описание, поиск и взаимодействие). Клиенты могут послать запрос к каталогу UDDI, чтобы получить список всех Web-сервисов, соответствующих заданным критериям поиска (например, "найти все Web-сервисы, связанные с получением метеорологических данных в реальном времени"). Идентифицировав подходящий Web-сервер в списке, возвращенном в результате UDDI-запроса, вы можете выяснить все возможности этого сервера. Если хотите, можете назвать UDDI "белой книгой" Web-сервисов XML.

В дополнение к UDDI-поиску, Web-сервис XML, построенный в рамках .NET, можно найти с помощью DISCO – этот несколько искусственный акроним расшифровывается, как Discovery of Web Services (поиск Web-сервисов). Используя файл статического поиска (*.disco) или динамического поиска (*.vsdisco), вы можете "афишировать" набор Web-сервисов XML, размещенных по конкретному адресу URL. Потенциальные клиенты Web-сервисов могут перейти к файлу *.disco Web-сервера, чтобы проверить связи всех опубликованных Web-сервисов XML.

Следует учитывать то, что по умолчанию динамический поиск отключен, поскольку имеется потенциальный риск нарушения защиты, если позволить IIS открыть весь набор Web-сервисов XML всем интересующимся объектам. В связи с этим службы DISCO здесь обсуждаться не будут.

Замечание. Если вы захотите активизировать поддержку динамического поиска для Web-сервера, прочитайте статью Q307303 базы знаний Microsoft на страницах http://support.microsoft.com

Итак, клиент знает, где размещен Web-сервис XML. Теперь клиент должен узнать функциональные возможности этого сервиса. Например, клиент должен иметь возможность узнать, что сервис имеет метод GetWeatherReport(), предполагающий использование некоторого набора параметров и возвращающий некоторое значение, чтобы клиент мог вызвать этот метод. Вы, возможно, догадываетесь, что это предполагает использование некоторого метаязыка, нейтрального в отношении всех платформ, языков и операционных систем. XML-метаданные, используемые для описания Web-сервисов XML, создаются на языке WSDL (Web Services Description Language – язык описания Web-сервисов).

Во многих случаях WSDL-описание Web-сервиса XML автоматически генерируется сервером IIS Microsoft, если поступающий запрос имеет суффикс ?wsdl. Вы увидите, что первичными потребителями WSDL-контрактов являются инструменты генерирования агентов. Например, утилита командной строки wsdl.exe (ее обсуждение будет предложено позже) генерирует клиентский C#-класс агента на основе имеющегося WSDL-документа.

В более сложных случаях (обычно с целью гарантии совместимости) при построении Web-сервисов многие разработчики используют подход, в рамках которого сначала вручную определяется WSDL-документ, поскольку упомянутая выше утилита командной строки wsdl.exe может генерировать описания интерфейса для Web-сервиса XML и на основе WSDL-определения.

После создания типа агента для взаимодействия с Web-сервисом XML клиент может вызывать доступные методы. Как уже подчеркивалось, соответствующие данные передаются с помощью сетевого протокола HTTP. В частности, для обмена информацией между потребителями и Web-сервисами можно использовать HTTP-методы GET и POST или SOAP.

В общем, основным вариантом выбора обычно оказывается SOAP, поскольку, как вы вскоре убедитесь, сообщения SOAP могут содержать XML-описания сложных типов (включая пользовательские типы и типы из библиотек базовых классов .NET), При использовании HTTP-протоколов GET и POST вам придется ограничиться более узким множеством типов XML-схемы.

Теперь, когда у вас есть база для понимания принципов функционирования Web-сервисов XML, мы с вами можем заняться построением такого объекта в рамках платформы .NET. Библиотеки базовых классов определяют целый ряд пространств имен, обеспечивающих взаимодействие с любой из доступных технологий использования Web-сервисов (табл. 25.1).

Таблица 25.1. Пространства имен для работы с Web-сервисами XML 

Замечание. Все пространства имен, связанные с Web-сервисами XML, содержатся в компоновочном блоке System.Web.Services.dll.

Несмотря на богатые функциональные возможности, обеспечиваемые всеми пространствами имен .NET, связанными с Web-сервисами XML, подавляющее большинство ваших приложений потребует непосредственного взаимодействия только с типами, определенными в System.Web.Services. Как становится ясно из табл. 25.2, количество таких типов достаточно невелико (что уже хорошо).

Таблица 25.2. Члены пространства имен System.Web.Services

Остальные пространства имен, показанные в табл. 25.1, могут быть полезны вам только в том случае, если вы захотите вручную взаимодействовать с WSDL-документом, службами поиска или соответствующими сетевыми протоколами. Все подробности можно найти в документации .NET Framework 2.0 SDK.

Как и любое другое приложение .NET, Web-сервисы XML можно создавать вручную, без использования интегрированной среды разработки, такой как, например, Visual Studio 2005. Чтобы прояснить возможности использования Web-сервисов XML, давайте построим пример простого Web-сервиса XML вручную. С помощью текстового редактора создайте новый файл с именем HelloWorldWebService.asmx (по умолчанию для обозначения файлов Web-сервисов .NET используется расширение *.asmx). Сохраните файл в подходящем месте на своем жестком диске (например, в папке C:\HelloWorldWebService), добавив следующее определение типа.

‹%@ WebService Language="C#" Class="HelloWebService.HelloService" %›

using System;

using System.Web.Services;

namespace HelloWebService {

 public class HelloService {

  [WebMethod]

  public string HelloWorld() {

   return "Hello!";

  }

 }

}

В основном, файл *.asmx выглядит аналогично любому другому определению пространства имён C#. Первым достойным внимания отличием является то, что здесь используется директива ‹%@WebService%›, которая должна, как минимум, указать название управляемого языка, используемого для определения соответствующего класса, и полное имя этого класса. В дополнение к атрибутам Language и Class директива ‹%@WebService%› может также содержать атрибут Debug, информирующий компилятор ASP.NET о необходимости генерирования символов отладки, и необязательное значение CodeBehind, идентифицирующее связанный файл программного кода поддержки в пределах необязательного каталога App_Code (см. главу 23). В этом примере мы не собираемся использовать внешний файл кода поддержки, а встроим всю необходимую программную логику непосредственно в файл

Кроме использования директивы ‹%@WebService%›, другой особенностью это-го файла *.asmx является использование атрибута [WebMethod], информирующего среду выполнения ASP.NET о том, что этот метод будет доступен для поступающих HTTP-запросов и должен позволять сериализацию возвращаемых значений в формате XML.

Замечание. В рамках HTTP могут быть доступными только члены, имеющие атрибут [WebMethod]. Члены, не обозначенные атрибутом [WebMethod], не могут вызываться агентом клиента

Напомним (снова см. главу 23), что WebDev.WebServer.exe является сервером Web-разработки ASP.NET, поставляемым в составе дистрибутива .NET Framework 2.0 SDK. И хотя WebDev.WebServer.exe не предполагается использовать для обслуживания Web-сервисов XML производственного уровня, этот инструмент позволяет запустить Web-содержимое непосредственно из локального каталога при отладке. Для проверки своего сервиса с помощью этого инструмента откройте окно командной строки Visual Studio 2005 и выполните следующую команду, указав свободный номер порта и физический путь к каталогу, содержащему ваш файл *.asmx.

WebDev.Webserver /port:4000 /path:"C:\HelloWorldWebService"

После запуска Web-сервера откройте любой браузер и укажите в его окне имя своего файла *.asmx, используя соответствующий номер порта.

http://localhost:4000/HelloWorldWebService.asmx

Вам будет показан список всех Web-методов, доступных по этому адресу URL (рис. 25.2).

Рис. 25.2. Тестирование Web-сервиса XML

Если в окне браузера вы щелкнете на ссылке HelloWorld, откроется другая страница, которая позволит вызвать [WebMethod], только что выбранный вами. В результате вызова HelloWorld() будет возвращена не буквальная строка .NET System.String, a XML-представление текстовых данных, возвращаемых Web-методом HelloWorld().

‹?xml version="1.0" encoding="utf-8"?›

‹string xmlns="bttp://tempuri.org/"›Hello!‹/string›

Теперь, когда вы проверили свой Web-сервис XML с помощью WebDev. WebServer.exe, перенесите файл *.asmx в виртуальный каталог IIS. Используя инструкции, предложенные в главе 23, создайте новый виртуальный каталог с именем HelloWS, который будет отображаться в физическую папку, содержащую файл HelloWorldWebServiсe.asmx. После этого вы получите возможность проверить свой Web-сервис с помощью ввода следующего значения URL в строке Web-браузера.

http://localhost/HelloWS/HelloWorldWebService.asmx

Как уже упоминалось, WSDL является метаязыком, описывающим многочисленные особенности Web-методов, доступных по данному адресу URL. Обратите внимание на то, что при проверке Web-сервиса XML автоматически генерируемая страница тестирования предлагает ссылку Service Description (Описание сервиса). В результате щелчка на этой ссылке к текущему запросу присоединяются символы ?wsdl. Когда среда выполнения ASP.NET получает запрос для файла *.asmx с таким прикрепленным суффиксом, она автоматически возвращает соответствующий WSDL-код, открывающий каждый доступный Web-метод.

В настоящий момент вам не следует беспокоиться о природе WSDL-кода или формате WSDL-документа. Пока что важно только понимать, что WSDL-код описывает то, как Web-методы могут вызываться с помощью имеющихся протоколов связи Web-сервиса XML.

Как вы только что убедились, работоспособность Web-сервисов XML можно проверить с помощью автоматически генерируемой HTML-страницы в браузере. Когда обнаруживается HTTP-запрос, указывающий на данный файл *.asmx, среда выполнения ASP.NET использует файл с именем DefaultWsdlHelpGenerator.aspx, чтобы создать HTML-страницу, позволяющую вызвать Web-методы, доступные по данному URL. Этот файл *.aspx можно найти в следующем каталоге (здесь, конечно, блок ‹версия› следует заменить на номер вашей текущей версии .NET Framework).

C:\Windows\Microsoft.NET\Framework\‹версия›\CONFIG

Если вы хотите, чтобы среда выполнения ASP.NET применяла пользовательский файл *.aspx для проверки ваших Web-сервисов XML, вы можете встроить в эту страницу дополнительную информацию (например, фирменный знак компании, дополнительные описания сервиса, ссылки на файлы справки и т.д.). Чтобы упростить себе задачу, большинство разработчиков сначала копируют существующий файл DefaultWsdlHelpGenerator.aspx в проект, а затем, используя этот файл в качестве исходного, нужным образом изменяют оригинальный HTML-документ и программный код C#.

Скопируйте файл DefaultWsdlHelpGenerator.aspx в каталог, содержащий HelloWorldWebService.asmx (например, C:\HelloWorldWebService). Переименуйте полученную копию в MyCustomWsdlHelpGenerator.aspx и измените какой-нибудь фрагмент HTML-кода, скажем, в области дескриптора ‹title›. Например, измените имеющийся код разметки

‹title›‹%#ServiceName + " " + GetLocalizedText("WebService'')%›‹/title›

на следующий.

‹title›Мой собственный

 ‹%#ServiceName + " " + GetLocalizedText("WebService") %›

‹/title›

После изменения HTML-содержимого создайте файл Web.config и сохраните его в текущем каталоге. Следующие XML-элементы дают указание среде выполнения использовать ваш пользовательский файл *.aspx, а не DefaultWsdlHelpGenerator.aspx.

‹!--Здесь указывается пользовательский файл *.aspx --›

‹configuration›

 ‹system.web›

  ‹webServices›

   ‹wsdlHelpGenerator href="MyCustomWsdlHelpGenerator.aspx" /›

  ‹/webServices›

 ‹/system.web›

‹/configuration›

При запросе своего Web-сервиса вы увидите, что строка заголовка браузера изменится в соответствии с указанным вами пользовательским содержимым. Кстати, если вы захотите отключить генерирование страницы помощи для данного Web-сервиса, вы можете сделать это с помощью элемента ‹remove› в файле Web.config.

‹!-- Отмена генерирования страницы помощи --›

‹configuration›

 ‹system.web›

  ‹webServices›

   ‹protocols›

    ‹!-- Этот элемент отменяет генерирование WSDL-документа --›

    ‹remove name="Documentation"/›

   ‹/protocols›

  ‹/webServices›

 ‹/system.web›

‹/configuration›

Исходный код. Файлы примера HelloWorldWebService размещены в подкаталоге, соответствующем главе 25.

Создав Web-сервис XML вручную, давайте посмотрим, как это делается в Visual Studio 2005. Выбрав File>New>Web Site из меню, создайте новый C#-проект Web-сервиса XML с именем MagicEightBallWebService и сохраните этот проект на своем локальном диске (рис. 25.3).

Замечание. Как и в случае Web-узла ASP.NET, файлы *.sln проектов Web-сервисов XML, созданных в Visual Studio 2005, размещаются в папке Мои документы\Visual Studio 2005\ Projects.

Рис. 25.3. Проект Web-сервиса XML в Visual Studio 2005

После щелчка на кнопке OK в окне создания сервиса Visual Studio 2005 будет сгенерирован файл Service.asmx, определяющий следующую директиву ‹%@WebService%›.

‹%@ WebService Language="C#" CodeBehind="~/App_Code/Servicе.cs" Class="Service" %›

Обратите внимание на то, что здесь используется атрибут CodeBehind, чтобы указать имя файла с программным кодом C#, определяющим соответствующий тип класса (этот файл по умолчанию размещается в каталоге App_Code проекта). По умолчанию Service.cs определяется так.

using System;

using System.Web;

using System.Web.Services;

using System.Web.Services.Protocols;

[WebService(Namespace="http://tempuri.org/")]

[WebServiceBinding(ConformsTo=WsiProfiles.BasicProfile1_1)]

public class Service: System.Web.Services.WebService {

 public Service() { }

 public string HelloWorld() {

  return "Hello World";

 }

}

В отличие от предыдущего примера HelloWorldWebService, здесь класс Service получается из базового класса System.Web.Services.WebService. Члены, определенные этим типом, будут рассмотрены чуть позже, а здесь достаточно подчеркнуть, что получать класс Service именно из этого базового класса совсем не обязательно.

Также обратите внимание на то, что класс Service имеет два (также необязательных) атрибута, [WebService] и [WebServiceBinding]. Роль этих атрибутов тоже будет рассмотрена немного позже.

Ваш Web-сервис XML MagicEightBall будет имитировать классическую говорящую игрушку, сообщающую предсказания. Для этого добавьте в класс Service следующий метод (существующий Web-метод HelloWorld() можно удалить).

[WebMethod]

public string TellFortune(string вопросПользователя) {

 string[] answers = {"Будущее неоднозначно", "Да", "Нет", "Вряд ли", "Спросите еще раз", "Определенно" };

 // Возвращение случайного ответа на вопрос.

 Random r = new Random();

 return string.Format("{0}? {1}", вопросПользователя, answers[r.Next(answers.Length)]);

}

Для проверки нового Web-сервиса XML просто запустите проект на выполнение (или для отладки) в Visual Studio 2005. Поскольку для метода ТеllFortune() требуется один входной параметр, автоматически генерируемая HTML-страница тестирования обеспечивает необходимое поле ввода (рис. 25.4).

Рис. 25.4. Вызов Web-метода TellFortune()

Вот возможный ответ на вопрос "Будет ли отремонтирован водосток в выходные?"

‹?xml version="1.0" encoding="utf-8"?›

‹string xmlns="http://tempuri.org/"›"Будет ли отремонтирован водосток в выходные? Вряд ли

‹/string›

Итак, к этому моменту вы создали два простых Web-сервиса XML: один вручную, а другой – с помощью Visual Studio 2005. Теперь у вас есть хорошая основа для углубленного обсуждения соответствующих вопросов, и начнем мы это обсуждение с рассмотрения роли базового класса

Исходный код. Файлы примера MagicEightBallWebService размещены в подкаталоге, соответствующем главе 25.

В процессе разработки сервиса HelloWorldWebService вы имели возможность убедиться том, что Web-сервис можно получить непосредственно из System.Object. Но по умолчанию Web-сервисы, созданные в Visual Studio 2005, автоматически получаются из базового класса System.Web.Services.WebService. Описания основных членов этого типа класса предлагаются в табл. 25.3.

Таблица 25.3. Основные члены типа System.Web.Services.WebService

Вы, возможно, уже поняли, что для построения Web-сервиса, способного осуществлять поддержку своего состояния с помощью переменных приложения и сеанса (см. главу 24), вы должны получить соответствующий тип из WebService, поскольку последний определяет свойства Aррlication и Session. С другой стороны, если вы строите Web-сервис XML, для которого не требуется "помнить" информацию о внешних пользователях, не требуется и расширение WebService. Мы снова рассмотрим процесс построения Web-сервиса XML позже, в ходе нашего обсуждения свойства EnableSession атрибута [WebMethod].

Класс Web-сервиса XML может быть помечен необязательным атрибутом [WebService] (не путайте его с базовым классом WebService). Этот атрибут поддерживает ряд именованных свойств, первым из которых является Namespace. Это свойство можно использовать для указания пространства имен XML, используемого в документе WSDL.

Вы, возможно, уже знаете, что пространства имен XML используются для создания контекста применения пользовательских XML-элементов в рамках конкретной группы (точно так же, как и пространства имен .NET). По умолчанию среда выполнения ASP.NET назначает для файла *.asmx фиктивное пространство имен XML http://tempuri.org. Аналогично по умолчанию Visual Studio 2005 назначает для Namespace значение http://tempuri.org.

Предположим, что в Visual Studio 2005 вы создали новый проект Web-сервиса XML с именем CalculatorService, определяющий следующие два Web-метода с именами Add() и Subtract().

[WebService(Namespace = "http://tempuri.org/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class Service: System.Web.Services.WebService {

 [WebMethod]

 public int Subtract (int x, int y) { return x – y; }

 [WebMethod]

 public int Add(int x, int y) { return x + y; }

}

Перед публикацией своего Web-сервиса XML вы должны указать соответствующее пространство имен, которое обычно представляет собой адрес URL узла, обслуживающего Web-сервис. В следующем варианте программного кода обратите внимание на то, что атрибут [WebService] позволяет установить именованное свойство Description, предлагающее описание вашего Web-сервиса.

[WebService(Description = "Чудесный Web-сервис калькулятора",

Namespace ="http://www.IntertechTraining.com/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class Service: System.Web.Services.WebService {…}

При запуске этого проекта вы обнаружите, что теперь автоматически сгенерированная страница тестирования не отображает сообщение с предложением заменить http://tempuri.org. Более того, если вы щелкнете на ссылке Service Description, чтобы просмотреть содержимое соответствующего документа WSDL, вы увидите, что атрибут TargetNamespace соответствует указанному вами пользовательскому пространству имен XML. Наконец, WSDL-файл теперь содержит элемент ‹documentation›, соответствующий указанному вами значению Description.

‹wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›

 Чудесный Web-сервис калькулятора

‹/wsdl:documentation›

Вы, наверное, уже догадались что вполне возможно построить пользовательскую утилиту (например, объектный браузер Web-сервиса XML) для считывания значений, содержащихся в контексте элемента ‹documentation›. Однако в большинстве случаев соответствующее значение будет использоваться файлом DefaultWsdlHelpGenerator.aspx.

Последним из рассматриваемых здесь свойств типа WebServiceAttribute является свойство Name, которое используется для указания имени Web-сервиса XML, водимого внешним пользователем. По умолчанию внешнее имя Web-сервиса идентично имени соответствующего типа класса (которым, в свою очередь по умолчанию является имя Service). Однако если вы хотите "отделить" имя класса .NET от соответствующего WSDL-имени, вы можете изменить атрибут [WebService] так, как показано ниже.

[WebService(Description = "Чудесный Web-сервис калькулятора",

 Namespace = "http://www.IntertechTraining.com/",

 Name = "CalculatorWebService")];

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

{…}

На рис. 25.5 показана страница тестирования, автоматически сгенерированная с помощью DefaultWsdlHelpGenerator.aspx с учетом указанного значения атрибута [WebService].

Рис 25.5. Web-сервис CalculatorWebService

В .NET 2.0 Web-сервис XML может содержать атрибут [WebServiceBinding]. Среди прочего этот атрибут используется для того, чтобы указать соответствие данного Web-сервиса XML "базовому профилю совместимости Web-сервисов (WSI) версии 1.1". Но что это значит? Если вы активно работаете с Web-сервисами XML, вы должны знать, что спецификации WSDL в процессе развития этой технологии изменялись. Вследствие этого вполне обычной оказывается ситуация, когда один и тот же элемент (или атрибут) WSDL имеет разные интерпретации в разных системах разработки (IIS, WSAD), Web-серверах (IIS, Apache) и архитектурах (.NET, J2EE).

Очевидно, для Web-сервиса XML это оказывается проблемой, поскольку одной из задач разработки является упрощение способа обработки информации в межплатформенном мультиархитектурном и многоязычном окружении. Чтобы решить проблему, для повышения уровня межплатформенной совместимости Web-сервисов организация WSI предлагает использовать открытые спецификации. В .NET 2.0 свойству ConformsTo атрибута [WebServiceBinding] можно назначить любое значение из перечня WsiProfiles.

public enum WsiProfiles {

 // Web-сервис не делает никаких заявлений о совместимости.

 None,

 // Web-сервис объявляет о совместимости

 // с базовым профилем WSI версии 1.1.

 BasicProfile1_1

}

По умолчанию Web-сервисы XML, генерируемые с помощью Visual Studio 2005, предполагают согласованность с базовым профилем WSI 1.1. Конечно, простое приравнивание свойства ConformsTo к WsiProfiles.BasicProfile1_1 не гарантирует, что каждый Web-метод будет действительно совместим с этим профилем. Например, одно из правил ВР 1.1 гласит, что каждый метод WSDL-документа должен иметь свое уникальное имя (т.е. ВР 1.1 не допускает перегрузку Web-методов). Но хорошей вестью здесь является то, что среда выполнения ASP.NET позволяет определить различные уровни соответствия ВР 1.1 и сообщит об этом во время выполнения.

В .NET 2.0 Web-сервисы XML автоматически проверяются на соответствие спецификациям базового профиля WSI версии 1.1 (ВР 1.1). В большинстве случаев это хорошо, поскольку позволяет создавать программное обеспечение с самыми широкими возможностями совместимости. Однако в некоторых случаях бывает нужно пренебречь совместимостью с ВР 1.1 (например, при создании внутренних Web-сервисов XML, когда совместимость не столь важна). Чтобы дать указание среде выполнения игнорировать нарушение правил ВР 1.1, установите свойство ConformsTo равным WsiProfiles.None, а свойство EmitConformanceClaims – равным false (ложь).

[WebService(Description = "Чудесный Web-сервис калькулятора",

 Namespace = "http://www.IntertechTraining.com/",

 Name = "CalculatorWebService")]

[WebServiceBinding(ConformsTo = WsiProfiles.None,

 EmitConformanceClaims = false")]

public class Service: System.Web.Services.WebService {…}

Как и следует ожидать, от значения, присвоенного свойству EmitConformanceClaims, зависит, будут ли при публикации WSDL-описания Web-сервиса учиты-ваться сообщения соответствия свойства ConformsTo. В данном случае нарушение правил ВР 1.1 разрешается, но автоматически генерируется страница тестирования все равно будет отображать предупреждения.

Чтобы полностью отключить проверку соответствия BP 1.1 для Web-сервиса XML, определите в соответствующем файле Web.соnfig элемент

‹conformanceWarnings›.

 ‹configuration›

  ‹webServices›

   ‹conformanceWarnings›

    ‹remove name="BasicProfile1_1" /›

   ‹/conformanceWarnings›

  ‹/webServices›

 ‹/system.web›

‹/configuration›

Замечание. Атрибут [WebServiceBinding] можно также использовать для определения предполагаемых связей конкретных методов по значению свойства Name. Соответствующие подробности можно найти в документации .NET Framework 2.0 SDK.

Атрибут [WebMethod] должен указываться для каждого метода, который вы хотите сделать доступным в рамках данного Web-сервиса XML. Как и большинство других атрибутов, тип WebMethodAttiibute может иметь целый ряд необязательных именованных свойств. Давайте рассмотрим каждую из имеющихся здесь возможностей по очереди.

Как и в случае атрибута [WebService], свойство Description атрибута [WebMethod] позволяет описать функциональные возможности Web-мeтoдa.

public class Service: System.Web.Services.WebService {

 [WebMethod(Description = "Вычитание целых чисел.")]

 public int Subtract (int x, int y) { return x – y; }

 [WebMethod(Description = "Сложение целых чисел.")]

 public int Add(int x, int y) { return x + y; }

}

При указании свойства Description в пределах атрибута [WebMethod] в WSDL-документ в контексте имени метода добавляется новый элемент ‹documentation›.

‹wsdl:operation name="Add"›

 ‹wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"› Выполняет сложение целых чисел.

 ‹/wsdl:documentation›

 ‹wsdl:input message="tns:AddSoapIn" /›

 ‹wsdl:output message="tns:AddSoapOut" /›

‹/wsdl:operation›

Одним из WSI-правил ВР 1.1 является то, что каждый метод в WSDL-документе должен быть уникальным. Таким образом, если вы хотите, чтобы ваш Web-сервис XML удовлетворял спецификациям ВР 1.1, вы не можете использовать перегруженные методы. Однако для примера предположим, что вы все-таки использовали перегрузку метода Add(), чтобы вызывающая сторона могла передать как два целых числа, так и два числа с плавающей точкой. В результате вы должны увидеть следующее сообщение среды выполнения.

Both Single Add(Single, Single) and Int32 Add(Int32, Int32) use the message name 'Add'. Use the MessageName property attribute to specify unique of the WebMethod custom message names for the methods.

(Сообщение гласит: Single Add(Single, Single) и Int32 Add(Int32, Int32) используют одно и то же имя 'Add' для своих сообщений; используйте свойство MessageName атрибута WebMethod, чтобы указать для этих методов уникальные пользовательские имена сообщений.)

Здесь лучшим решением является отказ от перегрузки метода Add(). Если же перегрузка необходима, для устранения конфликтов имен в документах WSDL можно использовать свойство MessageName атрибута [WebMethod].

public class Service: System.Web.Services.WebService {

 [WebMethod(Description = "Сложение чисел с плавающей точкой.",

  MessageName = "AddFloats")]

 public float Add (float x, float y) { return x + y; }

 [WebMethod(Description = "Сложение целых чисел.",

  MessageName = "AddInts")]

 public int Add(int x, int y) { return x + y; }

}

Поcле этого генерируемый WSDL-документ будет внутренне ссылаться на каждую из перегруженных версий метода Add() по уникальным именам (AddFloats и AddInts). Но с точки зрения агента на стороне клиента будет существовать только один перегруженный метод Add().

Вы, наверное, помните из главы 24 о том, что свойства Application и Session позволяют Web-приложению ASP.NET поддерживать данные состояния. Web-сервисы XML обеспечивают те же возможности с помощью базового класса System.Web.Services.WebService. Например, предположим, что ваш Web-сервис калькулятора поддерживает переменную уровня приложения (которая, таким образом, должна быть доступной любому сеансу), содержащую значение PI, как показано ниже.

public class CalcWebServicе: System.Web.Services.WebService {

 // Этот Web-метод обеспечивает доступ к переменной SimplePI

 // уровня приложения.

 [WebMethod(Description = "Получение значения РI.")]

 public float GetSimplePI() { return (float)Application["SimplePI"]; }

 …

}

Начальное значение переменной SimplePI уровня приложения можно установить в обработчике Application_Start(), определенном в файле Global.asax. Добавьте в свой проект глобальный класс приложения (щелкнув правой кнопкой мыши на пиктограмме проекта в окне обозревателя решений и выбрав Add New Item из появившегося меню), а затем измените Application_Start() так, как предлагается ниже.

‹%@ Application Language="C#" %›

‹script runat="server"›

void Application_Start(Object sender, EventArgs e) {

 Application["SimplePI"] =3.14F;

}

…

‹/script›

Вдобавок к поддержке переменных уровня приложения можно использовать свойство Session для поддержки сеансовой информации. Для примера реализуйте метод Session_Start() в файле Global.asax так, чтобы каждый зарегистрированный пользователь идентифицировался случайным значением.

‹%@ Application Language="C#" %›

‹script runat= "server"›

…

void Session_Start(Object sender, EventArgs e) {

 // Чтобы сделать доступными сеансовые данные Web-сервиса,

 // присвойте каждому пользователю случайное число.

 Random r = new Random ();

 Session["SessionRandomNumber"] = r.Next(1000);

}

…

‹/script›

С целью проверки в рамках класса Service создайте новый Web-метод, возвращающий присвоенное пользователю случайное значение.

public class Service: System.Web.Services.WebService {

 …

 [WebMethod(EnableSession = true,

  Description = "Получите ваше случайное значение!")]

 public int GetMyRandomNumber() { return (int)Session["SessionRandomNumber"]; }

}

Заметим, что здесь атрибут [WebMethod] явно устанавливает для свойства EnableSession значение true (истина). Этот шаг необходим, поскольку по умолчанию для любого Web-метода контроль его данных сеансового состояния отключен. Если вы теперь запустите два или три экземпляра браузера (чтобы сгенерировать множество идентификаторов сеанса), вы обнаружите, что каждый зарегистрировавшийся пользователь возвращает уникальное числовое значение. Например, первый пользователь может получить следующий XML-код:

‹?xml version="1.0" encoding="utf-8"?›

‹int xmlns="http://www.IntertechTraining.com/WebServers"›931‹/int›

в то время как второй может получить значение 472.

‹?xml verslon="l.0" encoding="utf-8"?›

‹int xmlns="http://www.IntertechTraining.com/WebServers"›472‹/int›

Наконец, напомним, что файл Web.config можно изменить с тем, чтобы в нем указывалось место, где должны запоминаться данные состояния для Web-сервиса XML. Для этого используют элемент ‹sessionState› (описанный в предыдущей главе).

‹sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /›

Исходный код. Файлы примера CalculatorService размещены в подкаталоге, соответствующем главе 25.

В последних нескольких примерах вы могли видеть отдельные фрагменты WSDL-кода. Напомним, что WSDL – это основанная на XML грамматика, предназначенная для описания возможностей взаимодействия внешних клиентов с Web-методами, доступными по данному адресу URL в рамках каждого из поддерживаемых протоколов связи. Во многих отношениях WSDL-документ может рассматриваться, как "контракт" между клиентом Web-сервиса и самим Web-сервисом. Это еще один метаязык. В частности, WSDL используется для описания следующих характеристик любого доступного Web-метода:

• имя Web-метода XML;

•  число, тип и порядок следования параметров (если таковые имеются);

• тип возвращаемого значения (если таковое предусмотрено);

• условия вызова HTTP GET, HTTP POST и SOAP.

В большинстве случаев WSDL-документы генерируются автоматически соответствующим Web-сервером. Напомним, что при добавлении суффикса?wsdl к адресу URL, указывающему на файл *.asmx, Web-сервер генерирует WSDL-документ для указанного Web-сервиса XML.

http://locаlhost/SomeWS/theWS.asmx?wsdl

Но если IIS автоматически генерирует WSDL-документ для данного Web-сервиса XML, зачем тогда нужно глубокое понимание синтаксиса генерируемых WSDL-данных? Ответ обычно зависит от того, как ваш сервис будет использоваться внешними приложениями. В случае Web-сервисов XML, предназначенных для "внутреннего" использования, сгенерированного Web-сервером WSDL-кода будет, как правило, достаточно.

Между тем. вполне возможно начать разработку Web-сервиса XML с создания WSDL-документа вручную (об этом уже говорилось выше). Главная идея начала разработки с создания WSDL-документа связана с вопросами совместимости. Вспомните о том, что до появления спецификации WSI различные инструменты построения Web-сервисов нередко генерировали несовместимые WSDL-описания. Если начинать разработку с WSDL-кода, вы можете построить документ так, как требуется.

Как вы можете догадаться, для начала разработки Web-сервиса XML с создания WSDL-документа требуется очень хорошее знание грамматики WSDL, обсуждение которой в контексте этой главы не предусмотрено. Но мы рассмотрим базовую структуру WSDL-документа. Разобравшись в основах, вы сможете оценить пользу утилиты командной строки wsdl.exe.

Замечание. Самую свежую информацию о языке WSDL можно найти на страницах http://www.w3.org/tr/wsdl.

Действительный документ WSDL открывается и закрывается корневым элементом ‹definitions›. В открывающем дескрипторе обычно определяются различные атрибуты xmlns. Они задают пространства имен XML, определяющие различные подчиненные элементы. Как минимум, элемент ‹definitions› должен указать пространство имен, где определены сами элементы WSDL (http://schemas.xmlsoap.org/wsdl). Для того чтобы быть полезным, открывающий дескриптор ‹definitions› должен, кроме того, указать пространства имен XML, определяющие простые типы данных WSDL, типы XML-схемы, элементы SOAP, а также целевое пространство имен. Например, вот как выглядит раздел ‹definitions› для нашего Web-сервиса калькулятора.

‹?xml version="1.0" encoding="utf-8"?›

‹wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns-mime="http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:tns="http://www.IntertechTraining.com/"

xmlns:s="http://www.w3.org/2001/XMLSchema"

xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

xmlns:http="http://schemes.xmlsoap.оrg/wsdl/http/"

targetNamespace="http://www.IntertechTraining.com/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›

…

‹/wsdl:definitions›

В контексте корневого элемента вы можете найти пять подчиненных элементов. Общий вид WSDL-документа должен быть примерно таким.

‹?xml version="1.0" encoding="utf-8"?›

‹wsdl:definitions …›

 ‹wsdl:types›

  ‹!-- Список типов, доступных для данного Web-сервиса --›

 ‹wsdl:/types›

 ‹wsdl:message›

  ‹!-- Формат сообщений --›

 ‹wsdl:/message›

 ‹wsdl:portType›

  ‹!-- Информация портов --›

 ‹wsdl:/portType›

 ‹wsdl:binding›

  ‹!-- Информация связывания --›

 ‹wsdl:/binding›

 ‹wsdl:service›

  ‹!-– Информация о самом Web-сервисе XML --›

 ‹wsdl:/service›

‹wsdl:/definitions›

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

Сначала мы рассмотрим элемент ‹types›, который содержит описания всех типов данных, предлагаемых Web-сервисом. Вы, возможно, знаете, что язык XML сам определяет ряд "базовых" типов данных, и все они определены в рамках пространства имен XML http://www.w3.org/2001/XMLSchema (которое должно быть указано в контексте корневого элемента ‹definitions›). Возьмем, например, метод Subtract() нашего Web-сервиса калькулятора, имеющий два входных параметра целочисленного типа. В терминах WSDL тип System.Int32 среды CLR описывается в контексте элемента ‹complexType›.

‹s:еlement name= "Subtract"›

 <s:comlexType>

  ‹s:sequence›

   ‹s:element minOccurs="1" maxOccurs="1" name="x" type="s:int" /›

   ‹s:element minOccurs=''1" maxOccurs="1" name="y" type="s:int" /›

  ‹/s:sequence›

 ‹/s:complexType›

‹/s:element›

Целое число, возвращаемое методом Subtract(), также описывается в рамках элемента ‹types›.

‹s:element name= "SubtractResponse"›

 ‹s:complexType›

  ‹s:sequence›

   ‹s:element minOccurs="1" maxOccurs="1" name="SubtractResult" type="s:int"/›

  ‹/s:sequence›

 ‹/s:complexType›

‹/s:element›

Если вы имеете Web-метод, возвращающий или получающий пользовательские типы данных, они также появятся в контексте элемента ‹complexType›. Детали того, как с помощью Web-метода сделать доступными пользовательские типы данных .NET, мы рассмотрим позже. Для примера предположим, что вы определили Web-мeтод, возвращающий структуру с именем Point.

public struct Point {

 public int x;

 public int y;

 public string pointName;

}

WSDL-описание для этой "сложной структуры" будет выглядеть примерно так.

‹s:complexType name="Point"›

 ‹s:sequence›

  ‹s:element minOccurs="1" maxOccurs="1" name="x" type="s:int" /›

  ‹s:element minOccurs="1'' maxOccurs="1" name="y" type= "s:int" /›

  ‹s:element minOccurs="0" maxOccurs="1" name="рointName" type="s:string" /›

 ‹/s:sequence›

‹/s:complexType›

Элемент ‹message› используется для определения формата обмена запросами и ответами данного Web-метода. Поскольку один Web-сервис позволяет передачу множества сообщений между отправителем и получателем, одному WSDL-документу позволяется определять множество элементов ‹message›. Как правило, в этих определениях используются типы, указанные в рамках элемента ‹types›.

Независимо от количества элементов ‹message›, определенных в документе WSDL, они обычно "присутствуют" парами. Первое определение представляет входной формат сообщения, а второе – выходной формат того же сообщения. Например, метод Subtract() Web-сервиса CalculatorWebService определяет следующие элементы ‹message›.

‹wsdl:message name="SubtractSoapIn"›

 ‹wsdl:part name="parameters" element="tns:Subtract" /›

‹/wsdl:message›

‹wsdl: message name="SubtractSoapOut"›

 ‹wsdl:part name="parameters" element="tns:SubtractResponse" /›

‹/wsdl:message›

Здесь вы видите только связь SOAP соответствующего сервиса. Как говорилось в начале этой главы, Web-сервисы XML могут вызываться с помощью SOAP или HTTP-методов GET и POST. Но если вы разрешите связь HTTP POST (соответствующие объяснения будут предложены позже), генерируемый WSDL-код должен продемонстрировать следующие данные ‹message›.

‹wsdl: message name="SubtractHttpPostIn"›

 ‹part name="n1" type="s:string" /›

 ‹part name="n2" type="s:string" /›

‹wsdl:/message›

‹wsdl:message name="SubtractHttpPostOut"›

 ‹part name="Body" element="s0:int" /›

‹wsdl:/message›

Элементы ‹message› сами по себе не слишком полезны. Однако на эти определения сообщений ссылаются другие части WSDL-документа.

Замечание. Не все Web-методы требуют и запроса, и ответа. Если Web-метод является "односторонним", для него необходим только элемент ‹message› запроса. Обозначить Web-метод, как односторонний, можно с помощью атрибута [SoapDocumentMethod].

Элемент ‹portType› определяет различные связи, которые могут возникать между клиентом и сервером, и каждая такая связь представляется вложенным элементом ‹operation›. Несложно догадаться, что самыми типичными операциями здесь должны быть SOAP, HTTP GET и HTTP POST. Однако есть и другие операции. Например, односторонняя операция позволяет клиенту отправить сообщение данному Web-серверу, но не получить ответ (это похоже на вызов метода без ожидания возвращаемого значения). Операция "требование-ответ" позволяет серверу отправить, запрос во время ответа клиента (что можно рассматривать, как дополнение операции "запрос-ответ").

Чтобы проиллюстрировать формат необязательного вложенного элемента ‹operation›, рассмотрим WSDL-определение для метода Subtract().

‹wsdl portType name="CalculatorWebServiceSoap"›

 ‹wsdl:operation name="Subtract"›

  ‹wsdl:input message="tns:SubtractSoapIn" /›

  ‹wsdl:output message="tns:SubtractSoapOut" /›

 ‹/wsdl:operation›

‹wsdl:/portType›

Обратите внимание на то, как элементы ‹input› и ‹output› ссылаются на соответствующее имя сообщения, определенное в рамках элемента ‹message›. Если бы для метода Subtract() был разрешен HTTP-метод POST, вы бы увидели следующий дополнительный элемент ‹operation›.

‹wsdl:portType name="CalculatorWebServiceHttpPost"›

 <wsdl:operation name="Subtract" ›

  ‹wsdl:input message="s0:SubtractHttpPostIn" /›

  ‹wsdl:output message= "s0:SubtractHttpPostOut" /›

 ‹wsdl:/operation›

‹wsdl:/portType›

Наконец, учтите то, что если данный Web-метод описан с помощью свойства Description, элемент ‹operation› будет содержать вложенный элемент ‹documentation›.

Этот элемент указывает точный формат обмена GET, POST и SOAP. Это самый "многословный" из всех элементов, содержащихся в контексте корневого элемента ‹definition›. Вот, например, определение элемента ‹binding› с описанием того, как вызывающая сторона может взаимодействовать с Web-методом MyMethod(). используя SOAP.

‹wsdl:binding name="СаlculatorWebServiceSoap12" type="tns:CalculatorWebServiceSoap"›

 ‹soap12:binding transport="http://schemas.xmlsoap.org/soap/http" /›

  ‹wsdl:operation name= "Subtract"›

  ‹soap12:operation soapAction="http://www.IntertechTraining.com/Subtract" style="document" /›

  ‹wsdl:input›

   ‹soap12:body use="literal" /›

  ‹/wsdl:input›

  ‹wsdl:output›

   ‹soap12:body use="literal" /›

  ‹/wsdl:output›

 ‹/wsdl:operation›

‹/wsdl:binding›

Наконец, у нас есть элемент ‹service›, который указывает характеристики самого Web-сервиса (например, его URL). Главной задачей этого элемента является описание множества портов, открытых данным Web-сервером. Для этого элемент ‹services› может использовать любое число вложенных элементов ‹port› (не путайте их с элементом ‹portType›). Вот как выглядит элемент ‹service› для CalculatorWebService.

‹wsdl:service name="CalculatorWebService"›

 ‹wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›

Чудесный Web-сервис калькулятора

 ‹/wsdl:documentation›

 ‹wsdl:port name="CalculatorWebServiceSoap" binding="tns:CalculatorWebServiceSoap" ›

  ‹soap:address location="http://localhost:1109/CalculatorWebService/ Service.asmx" /›

 ‹/wsdl:port›

 ‹wsdl:port name="CalculatorWebServiceSoap12" binding= "tns:CalculatorWebServiceSoap12"›

  ‹soap12:address location="http://localhost:1109/CalculatorWebService/Service.asmx" /›

 ‹/wsdl:port›

‹/wsdl:service›

Итак, как видите, WSDL-код, автоматически возвращаемый сервером ITS, не является сверхсложным, но, поскольку WSDL представляет собой грамматику на основе XML, этот код достаточно "многословен". Тем не менее, теперь вы должны лучше понимать роль WSDL, так что давайте рассмотрим немного подробнее протоколы связи Web-сервисов XML.

Замечание. Напомним, что пространство имен System.Web.Services.Description содержит множество типов, которые позволяют программно читать и обрабатывать "сырой" WSDL-код (можете проверить сами, если вас это интересует).

Строго говоря, Web-сервисы XML могут использовать для коммуникации любой RPC-протокол (например, DCOM или CORBA). Однако большинство Web-серверов встраивает соответствующие данные в тело HTTP-запроса и переправляет их адресату, используя для этого один из трех базовых способов связи (табл. 25.4).

Хотя каждый из подходов обеспечивает один и тот же результат (вызов Web-метода), от выбора протокола зависит то, какие типы параметров (и типы возвращаемых значений) могут пересылаться между заинтересованными сторонами. Протокол SOAP предлагает наибольшую гибкость, поскольку сообщения SOAP позволяют осуществлять обмен сложными типами данных (а также двоичными файлами) между вызывающей стороной и Web-сервисом XML. Однако для полноты давайте выясним роль стандартных HTTP-методов GET и POST.

Таблица 25.4. Режимы связи Web-сервисов XML

Хотя GET и POST кажутся привычными конструкциями, этот метод пересылки недостаточно гибок для обслуживания таких сложных элементов, как структуры и классы. При использовании SET и POST вы можете взаимодействовать с Web-методами, используя только типы, указанные в табл. 25.5.

Таблица 25.5. Типы данных, поддерживаемые методами GET и POST

По умолчанию HTTP-связь GET и POST не разрешена для удаленного вызова Web-сервисов XML. Однако HTTP-связь POST активизирована для вызова машиной локальных Web-сервисов (на самом деле именно этот режим использует автоматически генерируемая страница тестирования). Эти установки указываются в файле machine.config с помощью элемента ‹protocols›. Вот как выглядит соответствующий фрагмент

‹!-- В файле machine. config --›

‹webServices›

 ‹protocols›

  ‹add name="HttpSoap1.2" /›

  ‹add name="HttpSoap" /›

  ‹add name="Documentation" /›

  ‹!-- HTTP GET/POST отключены! --›

  ‹!-- ‹add name="HttpPost''/› --›

  ‹!-- ‹add name="HttpGet"/› --›

  ‹!-- Используется страницей тестирования Web-сервиса --›

  ‹add name="HttpPostLocalhost" /›

 ‹/protocols›

‹/webServiсes›

Чтобы снова разрешить использование HTTP-методов GET или POST для Web-сервиса, добавьте имена HttpPost и HttpGet в соответствующий локальный файл Web.config.

‹configuration›

 ‹system.web›

  ‹webServices›

   ‹protocols›

    ‹add name="HttpPost"/›

    ‹add name="HttpGet"/›

   ‹/protocols›

  ‹/webServices›

 ‹/system.web›

‹/configuration›

Снова напоминаем, что при использовании стандартных HTTP-методов GET и POST у вас нет возможности строить Web-методы, допускающие использование составных типов (например, DataSet ADO.NET или пользовательский тип структуры) в качестве параметров или возвращаемых значений. Для простых Web-сервисов это ограничение может быть вполне приемлемым. Однако при использовании связи SOAP вы можете строить гораздо более совершенные Web-сервисы XML.

Полный анализ возможностей SOAP выходит за рамки этого текста, однако следует понимать, что SOAP нельзя назвать специальным протоколом, который может использоваться наряду с другими существующими протоколами Интернет (HTTP, SMTP и др.). Общая задача SOAP, тем не менее, остается той же: обеспечить независимый от языка и платформы механизм вызова методов, использующих составные типы. Для этого SOAP преобразует каждый метод в сообщение SOAP.

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

‹soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xmlns:xsd="http://www.w3.org/2001/XMLSchema"  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"›

 ‹soap:Header›

  ‹!-- Необязательная информация заголовка --›

 ‹/soap:Header›

 ‹soap:Body›

 ‹!-- Информация вызова метода --›

 ‹/soap:Body›

‹/soap:Envelope›

Хотя при создании Web-сервиcов XML в рамках платформы .NET от вас не требуется понимания всех деталей SOAP, вы можете увидеть формат сообщения SOAP дня каждого доступного Web-метода с помощью автоматически генерируемой страницы тестирования. Например, если щелкнуть на ссылке для метода Add() нашего CalculatorWebService, вы увидите следующий запрос SOAP 1.1.

‹soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/ "›

 ‹soap:Body›

  ‹Add xmlns="http://www.IntertechTraining.com"›

   ‹x›int‹/x›

   ‹y›int‹/y›

  ‹/Add›

 ‹/soap:Body›

‹/soap:Envelope›

Соответствующий ответ SOAP 1.1 выглядит так.

‹soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"›

 ‹soap:Body›

  ‹AddResponse xmlns="http://www.IntertechTraining.com "›

   ‹AddResult›int‹/AddResult›

  ‹/AddResponse›

 ‹/soap:Body›

‹/soap:Envelope›

Теперь, когда у вас есть базовые знания о WSDL и SOAP, давайте выясним, как с помощью такого инструмента командной строки, как wsdl.exe строить программы клиента, взаимодействующие с удаленными Web-сервисами XML. В сущности, wsdl.exe решает две важные задачи.

• Генерирование файла сервера, функционирующего в качестве каркаса для реализации Web-сервиса XML.

• Генерирование файла клиента, функционирующего в качестве агента удаленного Web-сервиса XML.

Утилита wsdl.exe поддерживает ряд флагов командной строки, список которых можно увидеть, указав при вызове этой утилиты опцию -? в командной строже. Описания некоторых аргументов wsdl.exe приводятся в табл. 25.6.

Таблица 25.6. Подборка опций wsdl.exe

Замечание. Флаг /server утилиты wsdl.exe в .NET 2.0 больше не используется. Теперь базовый программный код для сервера генерируется с помощью /serverlnterfасе.

Одним из интересных вариантов использования утилиты wsdl.exe является генерирование серверного программного кода на основе WSDL-документа (с помощью опции /serverInterfасе). Очевидно, если вы начинаете разработку Web-сервиса XML с создания WSDL-документа, эта опция должна быть для вас очень важна. После того как файл исходного кода будет сгенерирован, вы получите хорошую исходную позицию для реализации каждого Web-метода.

Предположим, что вы создали WSDL-документ (CarBizObject.wsdl), в котором описывается единственный метод DeleteCar(), получающий на вход целое число и не возвращающий ничего. Этот метод предлагается Web-сервисом XML с именем CarBizObject, который может вызываться с использованием связи SOAP.

Чтобы сгенерировать серверный файл программного кода C# на основе этого WSDL-документа, откройте окно командной строки .NET и вызовите утилиту wsdl.exe с флатом /serverInterface, за которым должно следовать имя соответствующего WSDL-документа. Заметьте, что WDSL-документ может содержаться либо в локальном файле *.wsdl:

wsdl /serverInterface CarBizObject.wsdl

либо получаться динамически по данному URL с помощью указания суффикса ?wsdl:

wsdl /serverInterface http://localhost/CarService/CarBizObject.asmx?wsdl

После того как wsdl.exe обработает соответствующие XML-элементы, вы получите описания интерфейсов для каждого Web-метода.

[System.Web.Services.WebServiceBindingAttribute(

 Name="CarBizObjectSoap",

 Namespace="http://IntertechTraining.com/")]

 public partial interface ICarBizObjectSoap {

 …

 void RemoveCar(int carID);

}

Используя эти интерфейсы, вы можете определить класс, реализующий различные методы Web-сервиса XML.

Исходный код. Файл CarBizObject.wsdl размещен в подкаталоге, соответствующем главе 25.

Хотя это и нежелательно, но вполне возможно построить базовый программный код клиента, которым будет вручную открывать HTTP-соединение, строить SOAP-сообщения, вызывать Web-методы и выполнять обратную трансляцию поступающего XML-потока в типы данных CTS. Намного более предпочтительным подходом оказывается использование wsdl.exe для генерирования класса агента, который будет представлять Web-методы, определенные данным файлом *.asmx.

Для этого укажите (как минимум) имя генерируемого файла агента (с помощью флага /out) и место размещения WSDL-документа. По умолчанию wsdl.exe генерирует программный код агента на языке C#. Однако если вы хотите иметь программный код агента на другом языке .NET, вы можете использовать флаг /language. Следует также знать, что по умолчанию wsdl.exe генерирует программный код агента, предполагающего связь с удаленным Web-сервисом XML с помощью SOAP. Чтобы созданный агент использовал HTTP-метод GET или POST. следует указать соответствующий протокол связи с помощью /protocol.

Другим важным моментом в отношении генерирования программного кода агента с помощью wsdl.exe является то, что этому инструменту действительно требуется WSDL-документ Web-сервиса XML, а не просто файл с именем *.asmx. С учетом этого следует понимать, что если для разработки и тестирований Web-сервиса вы используете WebDev.WebServer.exe, то перед генерированием программного кода агента для клиента вы, скорее всего, захотите скопировать содержимое проекта в виртуальный каталог IIS.

Для примера предположим. что вы создали новый виртуальный каталог IIS (CalcService), содержащий данные проекта CalculatorService. После этого вы можете сгенерировать программный код агента клиента так.

wsdl /out:proxy.cs http://localhost/CalcService/Secrvice.asmx?wsdl

В качестве замечания подчеркнем, что wsdl.exe не определяет пространство имен .NET для упаковки генерируемых типов C#. если вы не укажете в командной строке флаг /n.

wsdl /out:proxy.cs /n:CalculatorClient http://localhost/CalcService/ Service.asmx?wsdl

Если открыть сгенерированный файл агента, вы найдете там тип, который получается из System.Web.Services.Protocols.SoapHttpClientProtocol (если, конечно, вы не указали другой протокол связи с помощью опции /protocol).

public partial class CalculatorWebService :

 System.Web.Services.Protocols.SoapHttpClientProtocol {

 …

}

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

Таблица 25.7. Основные члены типа SoapHttpClientProtocol

Заданный по умолчанию конструктор агента "жестко" определяет значение URL удаленного Web-сервиса и запоминает это значение в наследуемом свойстве Url.

public CalculatorWebService() {

 this.Url = "http://localhost/CalcServicе/Service.asmx";

}

Очевидным недостатком такого подхода является то, что при переименовании или перемещении Web-сервиса XML класс агента приходится обновлять и перекомпилировать. Для построения более гибкого типа агента wsdl.exe предлагает использовать флаг /appsettingurlkey (который можно сократить до /urlkey). Если указать в командной строке этот флаг, конструктор агента будет содержать программную логику для чтения URL с помощью ключа, содержащегося в файле *.config клиента.

wsdl /out:proxy.cs /n:СаlcClient /urlkey:CalcUrl http://localhost/CalcService/Serviсе.asmx?wsdl

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

public CalculatorWebService() {

 string urlSetting = System.Configuration.ConfigurationManager.AppSettings["CalcUrl"];

 if ((urlSetting != null)) {

  this.Url = urlSetting;

 } else {

  this.Url = "http://localhost./CalcService/Service.asmx";

 }

}

Соответствующий файл app.config на стороне клиента будет примерно таким.

‹?xml version="1.0" encoding="utf-8"?›

‹configuration›

 ‹appSettings›

  ‹add key="CalcUrl" value="http://localhost/CalcService/Service.asmx" /›

 ‹/appSettings›

‹/configuration›

Генерируемый агент определяет также поддержку синхронного вызова Web-методов. Например, синхронный вариант метода Subtract() реализуется так.

public int Subtract(int x, int y) {

 object[] results = this.invoke("Subtract", new object[] {x, y});

 return ((int)(results[0]));

}

Обратите внимание на то, что вызывающая сторона передает два параметра, "упакованные" в массив System.Object. Используя динамическое связывание, метод Invoke() передаст эти аргументы методу вычитания, размещенному по указанному адресу URL. По завершении этого (блокирующего) вызова будет обработан поступающий XML-код и результат будет возвращен вызывающей стороне в виде System.Int32 после соответствующего преобразования.

Поддержка асинхронного вызова Web-методов в .NET 2.0 сильно изменилась по сравнению с .NET 1.x. По своему предыдущему опыту вы можете знать, что агенты .NET 1.1 использовали методы BeginXXX()/EndXXX() для вызова Web-методов во вторичном потоке выполнения. Рассмотрите, например, следующие методы BeginSubtract() и EndSubtract().

public System.IAsyncResult BeginSubtract(int x, int y, System.AsyncCallback callback, object asyncState) {

 return this.BeginInvoke("Subtract", new object[] {x, y}, callback, asyncState);

}

public int EndSubtract (System.IAsyncResult asyncResult) {

 object[] results = this.EndInvoke(asyncResult);

 return ((int) (results[0]));

}

Хотя wsdl.exe все еще генерирует эти знакомые методы Begin/End, в .NET 2.0 они считаются устаревшими, поскольку заменены новыми методами XXXAsync().

public void SubtractAsync(int x, int y) {

 this.SubtractAsync(x, y, null);

}

Новые методы XXXAsync() (как и связанный с ними метод CancelAsync()) работают в паре с автоматически генерируемым вспомогательным методом (являющимся перегруженной версией некоторого специального метода XXXAsync()), который обрабатывает асинхронные операции, используя синтаксис событий C#. Если рассмотреть программный код агента, вы увидите, что wsdl.exe генерирует (для каждого Web-метода) пользовательский делегат, пользовательское событие и пользовательский класс "event args", чтобы получить соответствующий результат.

Теперь, когда вы лучше понимаете внутреннюю композицию генерируемого агента, давайте попытаемся его использовать. Создайте новое консольное приложение с именем CalculatorClient, добавьте в проект файл proxy.cs с помощью выбора Project>Add Existing Item из меню и добавьте ссылку на компоновочный блок System.Web.Services.dll. Затем измените метод Main() так, как предлагается ниже.

class Program {

 static void Main(string[] args) {

  Console.WriteLine("***** Забавы c агентами WS *****\n");

  // Создание агента.

  CalculatorWebService ws = new CalculatorWebService();

  // Синхронный вызов метода Add().

  Console.WriteLine("10 + 10= {0}", ws.Add(10, 10));

  // Асинхронный вызов метода Subtract с помощью

  // нового подхода .NET 2.0 на основе событий.

  ws.SubtractCompleted += new SubtractCompleteEventHandler(ws_SubtractCompleted);

  ws.SubtractAsync(50, 45);

  // Продолжение работы консоли для гарантии получения

  // результата вычитания.

  Console.RеаdLine();

 }

 static void ws_SubtractCompleted(object sender, SubtractCompletedEventArgs e) {

  Console.WriteLine("Baш ответ: {0} ", e.Result);

 }

}

Обратите внимание на то, что новая логика асинхронного вызова в .NET 2.0 непосредственно отображается в синтаксис событий C#, который, согласитесь, является более аккуратным по сравнению с использованием методов BeginXXX()/EndXXX(), интерфейса IAsyncResult и делегата AsyncCallback.

Исходный код. Проект CalculatorClient размещен в подкаталоге, соответствующем главе 25.

Утилита wsdl.exe, конечно, предлагает целый ряд аргументов командной строки, которые позволяют контролировать результат генерирования класса агента, но Visual Studio 2005 позволяет быстро сгенерировать файл агента, используя диалоговое окно Add Web Reference (Добавление Web-ссылки), которое можно вызвать из Меню Project. Как видно из рис. 26.6, в этом окне вы можете получить ссылки на существующие Web-сервисы XML, размещенные в самых разных местах.

Замечание. Диалоговое окно Add Web Reference не позволяет ссылаться на Web-сервисы XML, которые обслуживаются WebDev.WebServer.exe.

Рис. 25.6. Диалоговое окно Add Web Reference

Обратите внимание на то, что вы имеете возможность не только получить список Web-сервисов на своей локальной машине, но и запросить различные каталоги UDDI (соответствующие вопросы будут обсуждаться в конце главы). Так или иначе, в результате ввода в строку URL подходящего значения, указывающего на действительный файл *.wsdl или *.asmx, вы добавите в проект новый класс агента. Заметьте, что пространство имен агента (зависящее от URL источника) будет вложено в рамки пространства имен вашего клиента .NET. Так, если для клиента с именем MyClientApp добавляется ссылка на Web-сервис, размещенный на вашей локальной машине, вы должны указать C#-директиву using следующего вида.

using MyClientApp.localhost;

Замечание. В Visual Studio 2005 диалоговое окно Add Web Reference автоматически либо добавляет в проект новый файл app.config, содержащий значения URL ссылок на Web-сервисы XML, либо обновляет уже существующий.

В заключительном примере этой главы мы с вами выясним, как строить Web-сервисы, предлагающие доступ к пользовательским типам, а также к более "экзотическим" типам из библиотек базовых классов .NET. Для примера мы создадим новый Web-сервис XML, который будет способен обрабатывать массивы, пользовательские типы и объекты DataSet ADO.NET. Сначала создайте новый Web-сервис XML с именем CarSalesInfoWS, размещенный в виртуальном каталоге IIS.

Создайте Web-метод GetSalesTagLines(), который возвращает массив строк, представляющих данные текущих продаж различных автомобилей, и метод SortCarMakes(), который позволит вызывающей стороне передать массив несортированных строк, чтобы обратно получить новый массив отсортированных строк.

[WebService(Namespace="http://IntertechTraining.com/", Description="Автомобильный Web-сервис", Name="CarSalesInfoWS")]

[WebServiceBinding(ConformsTo=WsiProfiles.BasicProfile1_1)]

public class Service: System.Web.Services.WebService {

 [WebMethod(Description="Получение рекламных скидок")]

 public string[] GetSalesTagLines() {

  string[] currentDeals = {

   "Цены на Colt снижены на 50%",

   "Bce BMW комплектуются 8-канальным звуком",

   "Caravan бесплатно… спросите у дилера!"

  };

  return currentDeals;

 }

 [WebMethod(Description = "Сортировки списка марок")]

 public string[] SortCarMakes(string[] theCarsToSort) {

  Array.Sort(theCarsToSort);

  return theCarsToSort;

 }

}

Замечание. Страница тестирования, генерируемая с помощью DefaultWsdlHelpGenerator.aspx, не может вызывать методы, использующие в качестве параметров массивы типов.

Протокол SOAP позволяет передачу XML.предcтавлений пользовательских типов данных (таких как классы и структуры). Web-сервисы XML используют тип XmlSerializer для преобразования типа в XML-код (см. главу 17, где имеется более подробная информация по этому поводу). Напомним, что XmlSerializer:

• не выполняет сериализацию приватных данных: для сериализации используются только открытые поля и свойства;

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

• не требует использования атрибута [Serializable].

С учетом сказанного, наш следующий Web-метод будет возвращать массив структур SalesInfoDetails, определенных следующим образом.

// Пользовательский тип.

public struct SalesInfoDetails {

 public string info;

 public DateTime dateExpired;

 public string Url;

}

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

‹SalesInfoDetails›

 ‹info›Цены на Colt снижены на 50'%!‹/info›

 ‹dateExpired›2004-12-02T00:00:00.0000000-06:00‹/dateExpired›

 ‹Url›http://www.CarsRUs.com‹/Url›

‹/SalesInfoDetails›

Чтобы изменить поведение, предлагаемое по умолчанию, вы можете в определения своих типов добавить атрибуты, определенные в пространстве имен System.Xml.Serialization (снова см. главу 17).

public struct SalesInfoDetails {

 public string info;

 [XmlAttribute]

 public DateTime dateExpired;

 public string Url;

}

В результате будет получено следующее XML-представление данных.

‹SalesInfoDetails dateExpired="2004-12-02T00:00:00"›

 ‹info›Цены на Colt снижены на 50%!‹/info›

 ‹Url›http://www.CarsRUs.com‹/Url›

‹/SalesInfoDetails›

Реализация GetSalesInfoDetails() возвращает заполненный массив этой пользовательской структуры.

[WebMethod(Description="Get details of current sales")]

public SalesInfoDetails[] GetSalesInfoDetails() {

 SalesInfoDetails[] theInfo = new SalesInfoDetails[3];

 theInfo[0].info = "Цены на Colt снижены на 50%!";

 theInfo[0].dateExpired = DateTime.Parse("12/02/04");

 theInfo[0].Url = "http://www.CarsRUs.com";

 theInfo[1].info = "Все BMW комплектуются 8-канальным звуком";

 theInfo[1].dateExpired = DateTime.Parse("8/11/03");

 theInfo[1].Url = "http://www.Bmws4U.com";

 theInfo[2].info = "Caravan бесплатно… спросите у дилера!";

 theInfo[2].dateExpired = DateTime.Parse("12/01/09");

 theInfo[2].Url = "http://www.AllPinkVans.com";

 return theInfo;

}

Чтобы завершить создание нашего Web-сервиса XML, вот вам еще един Web-метод, который возвращает DataSet с данными таблицы Inventory базы данных Cars, созданной при изучении ADO.NET в главе 22.

// Получение списка всех машин из таблицы Inventory.

[WebMethod(Description = "Возвращает список машин из таблицы Inventory базы данных Cars")]

pubic DataSet SetCurrentInventory() {

 // Заполнение DataSet данными таблицы Inventory.

 SqlConnection sqlConn = new SqlConnection();

 sqlConn.ConnectionString = "data source=localhost;initial catalog=Cars;uid=sa;pwd=";

 SqlDataAdapter myDA= new SqlDataAdapter("Select * from Inventory", sqlConn);

 DataSet ds = new DataSet();

 myDA.Fill(ds, "Inventorу");

 return ds;

}

Исходный код. Файлы примера CarsSalesInfoWS размещены в подкаталоге, соответствующим главе 25.

Чтобы проверить работу нового Web-сервисa XML, создайте приложение Windows Forms и укажите в нем ссылку на CarsSalesInfoWS, используя диалоговое окно Add Web Reference в Visual Studio 2005 (рис. 25.7).

Pиc. 25.7. Добавление ссылки на CarsSalesInfoWS

Теперь просто используйте генерируемый агент для вызова доступных Web-методов. Вот один из возможных вариантов реализации формы.

using CarsSalesInfoCLient.localhost;

…

namespace CarsSalesInfoClient {

public partial class MainWindow: Farm {

 private CarSalesInfoWS ws = new CarSalesInfoWS();

 …

 private void MainWindow_Load(object sender, EventArgs e) {

  // Привязка к таблице.

  inventoryDataGridView.DataSource = ws.GetCurrentInventory().Tables[0];

 }

 private void btnGetTagLines_Click(object sender, EventArgs e) {

  string[] tagLines = ws.GetSalesTagLines();

  foreach (string tag in tagLines) listBoxTags.Items.Add(tag);

 }

 private void btnGetAllDetails_Click (object sender, EventArgs e) {

  SalesInfoDetails[] theSkinny = ws.GetSalesInfoDetails();

  foreach (SalesInfoDetails s in theSkinny) {

   string d = string.Format("Info: {0}\nURL:(1}\nExpiration Date:{2}", s.info, s.Url, s.dateExpired);

   MessageBox.Show(d, "Details");

  }

 }

}

На рис. 25.8 показан результат тестового запуска приложения.

Рис. 25.8. Клиент CarsSalesInfo

Когда клиент устанавливает ссыпку на Web-сервис, предоставляющий доступ к пользовательским типам, файл класса агента получает определения для каждого отрытого пользовательского типа. Так, если вы посмотрите на представление клиента для SalesInfoDetails (в генерируемом файле Reference.cs), вы увидите, что каждое поле инкапсулировано в строго типизованное свойство (также обратите внимание на то, что этот тип теперь определен, как класс, а не как структура).

[System.SerializableAtttribute()]

[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://IntertechTraining.com/")]

public partial class SalesInfoDetails {

 private string infoField;

 private string urlField;

 private System.DateTime dateExpiredField;

 public string info {

  get { return this.infoField; }

  set { this.infoField = value; }

 }

 public string Url {

  get { return this.urlField; }

  set { this.urlField = value; }

 }

 [System.Xml.Serialization.XmlAttributeAttribute()]

 public System.DateTime dateExpired {

  get { return this.dateExpiredField; }

  set { this.dateExpiredField = value; }

 }

}

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

Исходный код. Проект CarSaleslnfoClient размещен в подкаталоге, соответствующем главе 25.

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

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

UDDI (Universal Description, Discovery and Integration – универсальное описание, поиск и взаимодействие, стандарт UDDI) является инициативой, позволяющей разработчикам Web-сервисов "выставить" коммерческий Web-сервис в общеизвестном хранилище. Независимо от того, что вы могли сейчас подумать, UDDI не является технологией, поддерживаемой исключительно фирмой Microsoft. На самом деле IBM и Sun Microsystems имеют не меньшую заинтересованность в успexe инициативы UDDI. Как и следует ожидать, UDDI-каталоги обслуживаются многими поставщиками. Например, посвященный UDDI официальный Web-сайт Microsoft доступен по адресу http://uddi.microsoft.com. Официальный Web-сайт UDDI (http://www.uddi.org) предлагает множество "белых книг" и SDK, которые позволяют строить внутренние UDDI-серверы.

Вспомните о том, что диалоговое окно Add Web Reference позволяет не только получить список всех Web-сервисов XML, размещенных на вашей локальной машине (а также по известному URL), но и предъявить запрос к UDDI-серверу. Как правило, вы имеете на выбор следующие варианты.

• Выполнить обзор UDDI-сервера во внутренней сети вашей компании.

• Выполнить обзор спонсируемого фирмой Microsoft производственного UDDI-сервера.

• Выполнить обзор спонсируемого фирмой Microsoft тестового UDDI-сервера.

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

• Есть ли у вас Web-сервисы, имеющие отношение к погодным данным?

В том случае, когда UDDI-сервер имеет список Web-сервисов, связанных с прогнозом погоды, вы получите список всех зарегистрированных URL, предлагающих возможности, соответствующие вашему запросу. С помощью этого списка вы сможете выбрать подходящий вам Web-сервис и, в конечном итоге, получить WSDL-документ с описанием функциональных возможностей, cвязанных с обработкой погодных данных.

Для примера создайте новый проект консольного приложения и активизируйте диалоговое окно Add Web Reference. Затем выберите ссылку Test Microsoft UDDI Directory, которая приведет вас к тестовому UDDI-серверу Microsoft. После этого укажите слово weather (погода) в качестве критерия поиска. После выполнения запроса UDDI-каталогом вы получите список всех соответствующих Web-сервисов XML. Обнаружив Web-сервис XML который подойдет вам для использования в разработке, добавьте ссылку на этот сервис в свой проект. Как вы и должны ожидать, "сырой" WSDL-код будет проанализирован соответствующим инструментом разработки, и вы получите соответствующий агент на языке C#.

Замечание. Следует понимать, что центр тестирования является не более чем центром тестирования. Не удивляйтесь, если вы обнаружите там множество недействительных ссылок. При запросе производственных UDDI-серверов их URL оказываются гораздо более надежными, поскольку компаниям обычно приходится платить за то, чтобы они присутствовали в соответствующем списке.

В этой главе были рассмотрены базовые компоненты Web-сервисов и основные этапы их построения в пределах платформы .NET. Глава начинается с рассмотрений пространств имен (и базовых типов в этих пространствах имен), используемых при создании Web-сервисов. Вы узнали, что для разработки Web-сервиса в .NET требуется лишь немногим большее, чем применение атрибута [WebMethod] к каждому члену, который вы хотите сделать доступным в рамках типа, представляющего данный Web-cервис XML. Вы также можете (но это необязательно) сделать соответствующие типы производными от System.Web.Services.WebService, чтобы (среди прочего) получить доступ к свойствам Application и Session. В связи с основной темой обсуждения этой главы были также рассмотрены три взаимосвязанные ключевые технологии – это механизм поиска (UDDI), язык описания (WSDL) и протоколы связи (GET, POST или SOAP).

После создания любого числа членов с атрибутами [WebMethod] вы можете начать взаимодействие с Web-сервисом посредством промежуточного агента. Такой агент может быть сгенерирован с помощью утилиты wsdl.exe, а сам агент может использоваться клиентом подобно любому другому типу C#. Альтернативой инструменту командной строки wsdl.exe является использование Visual Studio 2005, где аналогичные возможности предлагает диалоговое окно Add Web Reference.