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

‹?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. Модель компиляции многомодульных страниц