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

Троелсен Эндрю

Опираясь на имеющиеся у вас знания .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%›, но их обсуждение предполагается привести позже.

Блок ‹script›

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

Декларация элемента ASP.NET

Последним из рассматриваемых здесь вопросов является структура определения элементов управления 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.