ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

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

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

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

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

 ‹/body›

Здесь 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).

Ответ на отправку POST

В настоящий момент для отправки данных формы целевому файлу *.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

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

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